Your vendor can call its product a screening tool, but a regulator or court decides which rules govern it. This is where your liability can begin, and a class action filed against Eightfold AI on January 20, 2026, shows how it opens.
According to the lawsuit, the platform scored applicants on a 0–5 scale and built dossiers that worked as undisclosed consumer reports. Although it's a hiring case, the mechanism applies to a credit-scoring or fraud-detection tool as well, especially when a score generated by such a system shapes decisions about people. If you buy such a system on the vendor's label without testing it, you carry the risk when a regulator or court rejects that label.
In the EU, the label that matters most is the AI Act's: whether your vendor's system counts as high-risk. For credit scoring, Annex III point 5(b) sets that line, and pure fraud detection sits outside it.
The AI Act's high-risk rules were due to apply to credit scoring on August 2, 2026, but the Digital Omnibus on AI pushed that to December 2, 2027. A vendor can use these extra months to say there's no rush to settle the question. That's accurate for AI Act compliance, but not for exposure under existing law. In the CJEU's 2023 SCHUFA ruling, the court held that an automated credit score counts as a decision under GDPR Article 22 when the lender relies heavily on it. Such decisions are generally prohibited unless an exception applies.
At NexLayer Content, we write for the vendors on the other side of these reviews, and we know where their answers fall apart. Below is the checklist to run before you sign.
Criterion One: Make the Vendor Show Its Classification
Start with the label. Ask which Annex III point the vendor believes covers its system. "We're compliance-ready" isn't an answer. A point number is.
Point 5(b) covers AI that evaluates creditworthiness or establishes a credit score. It excludes AI used to detect financial fraud, and vendors often misread that exclusion. A model that flags an anomalous transaction and routes it to a human reviewer sits outside the point. The same anomaly score used to auto-decline a loan sits inside it. Vendors also can't argue their way out with a "narrow task" claim, because the AI Act treats Annex III systems that profile individuals as always high-risk.
Put these four questions to the vendor:
Which Annex III point applies to your system, and why? Get the point number and the reasoning in writing.
Does one model or pipeline handle both fraud flagging and credit decisions? If so, each function needs its own scoping. A blended system can't borrow the fraud exclusion for its credit-scoring half.
Can you share the written classification rationale under Article 6?
Who is the provider and who is the deployer for this deployment? Article 16 obligations fall on the legal provider, and that's often not the party you'd assume.
Some vendors answer, "We're not sure yet, we're still assessing." Treat that as a red flag. A vendor that can't classify its own system can't tell you which obligations apply to it. That's the label risk from the top of this piece, now sitting in your contract.
Criterion Two: Ask for the Documents, Not the Description
A classification is a claim. Documentation is the evidence. Once a vendor confirms its system is high-risk under point 5(b), the AI Act attaches specific duties, and each one should leave a paper trail you can inspect:
Article 9: a risk management system that runs for the life of the product.
Article 10: data governance, including whether training data is representative and checked for bias.
Article 11: technical documentation detailed enough for a regulator to review.
Article 12: logging and record-keeping.
Article 14: human oversight mechanisms.
These high-risk rules apply from December 2, 2027. That's the date the duties take effect. It isn't the date a vendor should start building the evidence.
Don't accept a SOC 2 report as a substitute. SOC 2 tests security controls. It says nothing about bias testing or model logic. Ask for these instead:
The Annex IV technical documentation file, or a delivery date written into the contract with consequences for missing it.
Evidence of the Article 10 process: how the vendor tested training and validation data for demographic bias, and what it found.
A sample of the logs the system produces under Article 12, so you can check that they capture the events behind a decision.
The vendor's support for your own Article 27 fundamental rights impact assessment. If you deploy the system, that assessment is your obligation, and the vendor's cooperation decides whether you finish it on time.
A vendor that can describe these items but can't produce them has told you where its readiness stands.
Criterion Three: Don't Accept Certainty on Registration
Criterion One tests the vendor's label. Criterion Two tests its evidence. This one tests how it handles a question nobody has settled.
The Digital Omnibus pushed the main high-risk requirements to December 2, 2027. It left one rule on its original timing: the duty to register high-risk systems in the EU database. Euractiv reported on July 27, 2026, that the Commission's AI Act service desk told a recipient on July 9 that the registration obligation also starts in December 2027, in line with the Omnibus's adjusted timeline. Euractiv's reading of the law differs. Because that article wasn't itself pushed back, it said, companies could still be expected to register by August 2, 2026. The Commission didn't respond to its request for clarification.
There's a second complication. The database vendors would register in doesn't exist yet. Euractiv reports the Commission expects to launch it in the third quarter of 2027, though the Commission hasn't confirmed that publicly.
So if a vendor tells you, "Registration isn't required until 2027, full stop," it is relying on a service desk message, not settled law. Ask the vendor to put its position in writing. Then ask what happens to your contract if the interpretation goes the other way.
That's a contract question, so settle it in the contract. Add a clause that assigns responsibility for registration under whichever reading prevails.
Criterion Four: Put Dates in the Contract
The first three criteria test what the vendor knows today. This one covers what it must deliver later.
Although it seems the application of the high-risk rules is months away, you still need to rush. The risk management system, the bias-tested data pipeline, and the logging that meets Article 12 each take months to build and validate. One vendor guide puts the full build at 8 to 14 months for a provider starting from scratch. A vendor that begins in mid-2027 starts too late.
So write the schedule into the contract:
Require quarterly evidence of progress on Articles 9 through 15, not one attestation delivered in November 2027.
Require notice within a fixed number of days if the vendor changes how it classifies its own system.
That second clause matters most. If a vendor reclassifies mid-contract, say from fraud detection to credit scoring, the obligations that attach to it change too. You need lead time to respond, not a surprise.
Start With the Classification Question
Pull this list up before your next vendor call, and open with one question. Which Annex III point covers your system, who is the provider, and where is the written rationale? Everything else follows from the answer. A vendor that can't state its classification can't produce the documents, settle registration, or commit to a schedule.
December 2, 2027, gives you time to ask these questions properly. It doesn't give the vendor time to answer them late. The buyers who write evidence dates into contracts now will hold the proof when the rules start to apply.
Published by NexLayer Content. We write evidence-led thought leadership for B2B FinTech, RegTech, and technical-infrastructure companies.