Your credit-scoring AI has the same problem your hiring AI does
If your underwriting model uses anything derived from social media, browsing behaviour or device metadata to adjust a credit or insurance decision, check it against Article 5 before you check it against Annex III. One of
If your underwriting model uses anything derived from social media, browsing behaviour or device metadata to adjust a credit or insurance decision, check it against Article 5 before you check it against Annex III. One of those buckets doesn't have a 2027 deadline.
Credit scoring and insurance risk assessment are both named explicitly in Annex III as high-risk. Annex III(5)(b) for creditworthiness assessment, Annex III(5)(c) for life and health insurance risk assessment and pricing. That bucket gets you to 2 December 2027 with full obligations: documented risk assessment, technical documentation, bias testing, human oversight, an audit trail. Serious, but a deadline you can plan around.
The other bucket is Article 5, and it is already in force. Two prohibitions that show up constantly in underwriting models without anyone flagging them:
- Social scoring (Article 5(1)(c)): evaluating or classifying people based on social behaviour or inferred personal characteristics, where it leads to detrimental treatment in unrelated contexts. A model that downgrades a loan applicant over unrelated social-media activity sits closer to this than to ordinary underwriting.
- Emotion or personality inference from biometric signals feeding a financial decision. Same Article 5(1)(f)/(c) logic as the hiring-AI case, different pipeline.
Here's the uncomfortable part for engineering teams. Whether a feature crosses from "aggressive but high-risk-compliant underwriting" into "prohibited" is usually not visible from accuracy metrics or feature importance. It's about what the feature is derived from. A data-lineage question, not a model-quality one.
That's the gap Opencomplai's rule engine targets. It looks at what a pipeline actually imports and what data sources feed a scoring decision, and flags Article 5 patterns the way a SAST tool flags a known-bad crypto primitive. Before the PR merges, not after a regulator asks. The detection logic for both buckets is open, not behind a sales call: github.com/Opencomplai/opencomplai.
I'm a software engineer, not a lawyer, so check the Article references with your own counsel.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.