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; it does not trace data sources or lineage. Under scan --ai-intent it also matches call-site and identifier names against its Article 5 signal lists, the way a SAST tool flags a known-bad crypto primitive by name, so a hit is reported as a finding in the scan output. Whether it fails the build depends on --fail-on, and a finding is not a legal determination. Credit scoring is Annex III area 5, which the default scan has no signal for; only scan --ai-intent reads it, and the benchmark behind it is a baseline measured on synthetic programs, not on real repositories. Treat a hit as something to check, not as a determination. The aim is to surface it 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.

Release 0.12.0 note: credit scoring is Annex III area 5. The default scan has no signal for it. scan --ai-intent reads it. The project's benchmark covers 24 synthetic programs labelled by one author, so it is a baseline, not accuracy on real repositories.