Executive Summary
A bank that has spent the past year preparing its credit scoring models for the EU AI Act is not done preparing. It has built one of two required programs, and the second one doesn’t live in the same department, run on the same internal timeline, or answer to the same set of questions during an audit.
The habit is understandable. When banking compliance teams hear “EU AI Act,” they hear “lending.” Credit scoring is the obvious high-risk use case.
It sits inside risk and compliance functions that already run conformity assessments for other regulations, and it has been the headline example in nearly every AI Act briefing aimed at financial services.
But Annex III does not list one high-risk category for banks. It lists two, and they do not share an owner, a documentation set, or a conformity assessment.
Two Categories, Two Functions
Annex III point 5 covers access to essential services: creditworthiness assessment, credit scoring, and insurance risk pricing. This is the track banks have already built compliance programs around: inside risk and credit modeling teams.
Annex III point 4 covers employment and worker management: recruitment and selection tools, CV and resume screening, candidate ranking, interview analysis, and systems used for promotion, task allocation, performance evaluation, or termination decisions.
For a bank or credit union, this is the ATS plugin scoring resumes, the video-interview tool ranking candidates, the workforce management platform flagging performance outliers. It sits inside HR, not risk.
Both use cases are listed in Annex III and will generally be treated as high-risk when the system materially influences the relevant decision. Article 6(3) provides limited exceptions for certain Annex III systems, while systems that perform profiling of natural persons remain high-risk. Where a system is classified as high-risk, providers and deployers have distinct obligations under the Act.
A bank that has fully documented its credit-scoring AI has not, by doing so, satisfied the separate requirements that may apply to a high-risk recruitment or worker-management AI system.
The Deadline Shift Didn’t Merge the Tracks
Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026. It moved the application of Chapter III, Sections 1, 2 and 3 for high-risk AI systems classified under Article 6(2) and Annex III to 2 December 2027. The revised date applies equally to the relevant creditworthiness and employment use cases.
The extension does not merge the underlying use cases or eliminate the need to assess each system and its applicable obligations separately. Banks may choose to manage that work through different teams or through a cross-functional AI-governance program, depending on their operating model.
Under the final text of Regulation (EU) 2026/1744, 2 December 2027 is the specified application date for the relevant Annex III high-risk-system requirements.
Treating the delay as a single extended runway for “AI Act compliance” is how a bank can end up well-prepared on lending AI and underprepared on hiring AI. The two use cases remain separate areas of compliance work.
Governance Policy Isn’t the Same as a Governed System
Knowing both tracks exist is step one. Proving, on demand, who reviewed a score and what override existed is step two, and that’s an execution problem, not a policy one.
Download Whitepaper: Don’t Just Display the Work. CCaaS AI Adoption Requires Governing the Execution
Where GDPR Adds a Second Layer, on Both Tracks
GDPR Article 22 may also apply where a decision is based solely on automated processing, including profiling, and produces legal effects or similarly significant effects on the individual. Article 22 contains specified exceptions, and where applicable it also requires safeguards that can include the right to obtain human intervention, express a point of view, and contest the decision.
Credit decisions can raise the same Article 22 issue where they are based solely on automated processing and produce legal or similarly significant effects on the individual.
AI Act conformity and GDPR compliance are cumulative on both tracks, not substitutes for each other, which means “the model passed conformity assessment” is not the same claim as “the decision process is lawful.”
What This Means for SI and CCaaS Partners
This split doesn’t stop at the bank’s door. Every system integrator and CCaaS vendor that sells, configures, or embeds recruitment scoring, resume screening, or credit decisioning tools into a bank’s environment needs to know which side of the provider/deployer line they’re standing on, and it isn’t always the side they assumed.
Where the Obligation Actually Sits:
- The default assumption. Most SIs and CCaaS vendors price and staff their compliance exposure as deployers: someone else’s system, integrated into someone else’s environment, with someone else holding the conformity assessment.
- The Article 25 trigger. A distributor, importer, deployer, or other third party can become the provider of a high-risk AI system if it puts its name or trademark on an existing high-risk system, makes a substantial modification while the system remains high-risk, or changes the intended purpose of an existing AI system so that it becomes high-risk. Integration alone is not the statutory trigger.
- What shifts with it. Provider status under Article 25 carries the full weight of provider obligations: conformity assessment, technical documentation, quality management, and post-market monitoring, on top of whatever deployer duties the bank still owes.
- Where it shows up in practice. A CCaaS platform bundling a third-party interview-scoring add-on into its own offering. An SI customizing and reselling a credit decisioning module under its own integration layer. Both are common packaging decisions that can quietly convert a deployer-priced engagement into a provider-level one.
- The contract requirement that follows. Article 25(4) requires the provider of a high-risk AI system and a third party supplying an AI system, tools, services, components, or processes used or integrated in that system to specify, by written agreement, the information, capabilities, technical access, and other assistance needed for the provider to comply. The paragraph includes an exception for certain free and open-source components. For a partner selling into regulated CX, the contract stack itself becomes part of the compliance surface, not just the software.
- What’s actually at stake. This is not a hypothetical audit finding. It is the difference between a partner who can tell a bank exactly what obligations transfer at the point of integration, and one who finds out during the bank’s own conformity review that the answer was “more than we said.”
The same splitting problem shows up outside banking, too: in healthcare. It’s not two tracks but three.
The Systems Gap Underneath the Policy Layer
The instinct in many banks, and many partners selling into them, is to solve this with a single AI governance policy document that references both use cases. That closes a paperwork gap without closing the actual gap, which is that credit scoring and recruitment AI run on different platforms, produce different audit trails, and report through different chains of accountability.
A policy that says both must be governed doesn’t make either system capable of proving, on demand, who reviewed a given output, what data fed it, and what override existed.
That’s the same execution gap NovelVox has been describing across every regulated CX workflow: AI can produce a recommendation, a score, a ranking, but something still has to enforce accountability for that output inside the systems where the decision actually lives, whether that’s a core banking platform or an applicant tracking system.
That means checks and processes are governed, authorized, traced, and enforced at the point of execution, not just documented at the policy level.
A credit scoring model and a resume screening tool both need that discipline. Neither one inherits it from the other, and neither does a partner’s integration layer sitting between them and the bank.
The Practical Takeaway
If your bank’s AI Act program has an owner, ask which track they own. If the answer is credit scoring, someone still needs to own recruitment and worker management, on its own timeline, with its own documentation, reporting into its own chain.
If you’re an SI or CCaaS partner selling into that bank, ask the same question about your own integration: which side of Article 25 are you actually on. Two tracks, two owners, two systems, and every partner in the chain accountable for knowing which one they touched. Treating it as one is how the second one gets discovered during an audit instead of before one.
