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.
| Download Case Study: How a Leading U.S. Bank Enabled Secure, Transaction-Ready Self-Service With CCIP |
Both are standalone high-risk systems under Annex III. Both require conformity assessment, technical documentation, human oversight design, and registration. Neither obligation sets transfers to the other.
A bank that has fully documented its credit scoring model has produced zero percent of what Annex III point 4 requires for its recruitment software.
The Deadline Shift Didn’t Merge the Tracks
The Digital Omnibus provisional agreement of May 2026, which reached political agreement on May 7, 2026 and formally entered into force on July 27, 2026, pushed Annex III standalone high-risk obligations from August 2026 to December 2027. That extension applies identically to both tracks. It buys time.
It does not consolidate them into a single compliance motion, and it does not change the fact that two different internal teams now need to run two separate readiness programs on two different timelines, each tied to its own internal budgeting cycle.
That date functions as an outer limit rather than a fixed one. The European Commission can move it earlier if it formally confirms that the necessary technical standards are ready, and that confirmation could come with as little as six months’ notice.
Treating the delay as a single extended runway for “AI Act compliance is how a bank ends up well-prepared for a regulatory exam on lending and unprepared for one on hiring. The two tracks were never one item on the list.
| Also Read: How are AI Solutions Transforming Contact Centers? |
Where GDPR Adds a Second Layer, on Both Tracks
Neither track sits alone even within its own domain. Automated hiring decisions with significant effect on a candidate already trigger GDPR Article 22, which restricts fully automated decision-making absent a narrow legal basis, typically satisfied by ensuring a human meaningfully reviews the outcome before a rejection is final.
Automated credit decisions carry the same Article 22 exposure.
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. That assumption breaks the moment a vendor integrates a component and puts it into service under its own brand. Doing so can make the vendor the provider of the high-risk system, not just a supplier feeding one, even without having built the underlying model.
◉ 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 also requires the provider to have written contractual terms in place with every upstream supplier of components integrated into the system, on both Annex III tracks. 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?
Typically HR, not risk or compliance. Since most banks build their AI Act program around credit scoring, it sits inside teams that already run conformity assessments for lending. Recruitment and worker management tools, like ATS plugins and interview-scoring software, fall outside that structure and often have no assigned owner until an audit forces the question.
Q3: Did the Digital Omnibus delay change what banks need to prepare for?
The May 2026 provisional agreement pushed Annex III standalone high-risk obligations from August 2026 to December 2027, pending formal adoption. That extension applies equally to both tracks. It buys time on the calendar; it doesn’t merge the two compliance programs or reduce the work required on either one.
Q4: Does passing GDPR compliance cover AI Act obligations for automated hiring or lending decisions?
No. Automated decisions with significant effect on a candidate or applicant trigger GDPR Article 22 on top of AI Act conformity requirements, on both tracks. A model passing conformity assessment is a separate claim from the decision process being lawful under GDPR. The two obligations are cumulative.
Q5: When does a system integrator or CCaaS vendor become a “provider” under the AI Act instead of a deployer?
Under Article 25, integrating a high-risk AI component and putting it into service under your own brand can shift you from deployer to provider, even if you didn’t build the underlying model. That shift brings full provider obligations: conformity assessment, technical documentation, quality management, and post-market monitoring, in addition to whatever the bank still owes as deployer.
