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.
FAQs:
Q1: Does the EU AI Act treat credit scoring and hiring AI as the same compliance obligation?
No. Annex III lists them as two separate high-risk categories: point 5 covers creditworthiness assessment and credit scoring, point 4 covers recruitment, candidate ranking, and worker management tools. Each requires its own conformity assessment, technical documentation, and human oversight design. Completing one does not satisfy the other.
Q2: Which team inside a bank is responsible for AI Act compliance on hiring tools?
Ownership will depend on the bank’s governance model. HR will usually be a key stakeholder for recruitment and worker-management AI, but legal, compliance, risk, data protection, technology, procurement, and AI-governance teams may also have responsibilities. The important point is to ensure that employment-related AI systems are explicitly identified, assessed, and assigned accountable owners.
Q3: Did the Digital Omnibus delay change what banks need to prepare for?
Regulation (EU) 2026/1744 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 later date applies to the relevant creditworthiness and employment use cases, but each system still needs to be assessed against the obligations that apply to its role and classification.
Q4: Does passing GDPR compliance cover AI Act obligations for automated hiring or lending decisions?
No. The GDPR and the AI Act can apply cumulatively. GDPR Article 22 is relevant where a decision is based solely on automated processing and produces legal or similarly significant effects, while the AI Act imposes separate requirements on systems and operators where its conditions are met. Compliance with one regime does not, by itself, establish compliance with the other.
Q5: When does a system integrator or CCaaS vendor become a “provider” under the AI Act instead of a deployer?
Under Article 25, a distributor, importer, deployer, or other third party can be treated as the provider of a high-risk AI system if it puts its name or trademark on an existing high-risk system, substantially modifies a high-risk system while it remains high-risk, or changes the intended purpose of an existing AI system so that it becomes high-risk. In those circumstances, the party assumes the provider obligations that apply under the Act.
