EU AI Act for Credit Scoring: Annex III Classification and Article 12 Logging
Annex III, point 5(b) of the EU AI Act classifies AI used to evaluate the creditworthiness of natural persons or establish their credit score as high-risk. The classification can trigger Article 12 logging, Article 13 transparency, Article 14 human oversight, and Article 26 deployer obligations. Regulation (EU) 2026/1744 moved the Annex III application date to 2 December 2027. This piece explains the classification, the evidence a credit-scoring deployment needs, and the limits of an HTTP AI gateway.
Annex III, point 5(b) of the EU AI Act classifies AI systems used to evaluate the creditworthiness of natural persons or to establish their credit score as high-risk. The classification brings Title III requirements into scope. Automatic logging, deployer-facing transparency, human oversight, and the operator's use obligations each need a concrete implementation. Regulation (EU) 2026/1744 moved the application date for Annex III high-risk-system requirements to 2 December 2027. Article 99 establishes administrative-fine tiers, subject to the specific provision and operator role at issue.
Credit-scoring teams need evidence that explains a model-assisted decision months after it was made. Application logs can provide part of that evidence, yet a production review also needs traceable inputs, the actor context available to the system, model and policy versions, and the resulting human decision.
I want to walk through what the Annex III classification covers, what the operational requirements actually look like, and what the architecture for compliant credit scoring AI use looks like.
TL;DR
AI used to evaluate a natural person's creditworthiness or establish a credit score falls within Annex III, point 5(b). Regulation (EU) 2026/1744 sets 2 December 2027 as the Annex III application date. A credit-scoring programme needs evidence across the model request, case workflow, and human review; an HTTP gateway only records requests that route through it.
Mandate
Annex III, point 5(b) covers AI systems used for two related purposes: evaluating creditworthiness of natural persons, and establishing credit scores for natural persons. The classification applies regardless of whether the AI is the sole decision-maker or supports a human decision.
Title III, Chapter 2 contains the applicable high-risk-system requirements. Articles 12, 13, 14, and 26 shape the evidence and operating model a credit provider must prepare.
Article 12: automatic logging
Article 12 requires the AI system to "technically allow for the automatic recording of events (logs) over the lifetime of the system." The recording must enable identification of risk-creating situations, facilitate post-market monitoring, and enable monitoring of the system's operation. Article 19 sets retention duties for providers. Article 12 and the system's technical documentation should guide the event fields a provider and deployer retain for each use case.
Article 13: transparency to deployers
The credit-scoring AI provider must supply instructions for use that the deployer can act on. The instructions cover the system's intended purpose, its limitations, the human oversight measures, and the technical and organizational measures the deployer should take.
Article 14: human oversight
The system must be designed so that natural persons can effectively oversee its operation while it is in use. Oversight measures include the ability to fully understand the system's capacities and limitations, remain aware of the automation bias risk, correctly interpret the system's output, and intervene or override decisions.
Article 26: deployer obligations
The deployer (the bank or fintech that uses the credit-scoring AI) must use the system in accordance with its instructions, assign human oversight to people with appropriate competence and authority, monitor the system, and retain automatically generated logs for at least six months unless other Union or national law requires longer.
Compliance gap
Credit scoring AI deployments today have several structural gaps under Article 12.
Application-controlled audit logs fail under three conditions
The credit decision system writes logs at the application layer. The same application that handles the credit decision also writes the audit log. Self-attestation by the system under audit fails the traceability test. The logs can be selectively written, modified, or lost on application crash.
Natural-person identification is missing
Article 19 requires the log to identify the natural persons involved in result verification. Most credit-scoring AI deployments call model APIs using static service credentials issued to the credit decision application. The credential identifies the application. The natural person behind a specific credit decision (the underwriter, the credit analyst, the verification specialist) is not recorded at the AI request layer.
Vendor and embedded-AI usage is invisible
A material share of credit scoring AI flows through vendor SaaS tools that embed model calls under the hood. The fintech's credit decision platform uses ML internally. The credit bureau's pre-screen tool uses an LLM to interpret a request. The customer-onboarding platform uses a model to extract data from documents. The bank or fintech remains the deployer under Article 26 and inherits the disclosure obligation. The vendor's embedded AI usage is invisible from the deployer's audit trail.
Reference database checks are not recorded
Article 19 requires logging of the reference databases checked. Credit scoring AI often consults multiple data sources during evaluation. The credit bureau pull, the alternative data lookups, the fraud database checks. Each one needs to appear in the audit record.
Mandate vs. Compliance
The letter of Article 12 reads at one level of abstraction. The infrastructure to survive a competent authority's review operates several levels lower.
The questions a competent authority will ask
The questions that follow an Article 12 inquiry into a credit decision are specific. Which credit decisions touched this applicant? Who initiated each request? Which reference databases were checked? What was in the prompt to the model? What policy governed the decision? Can you produce, in writing, a tamper-evident record showing all of the above?
What surviving a review actually requires
An evidence architecture for model requests used in credit scoring should produce a record containing:
- A verified identity for the natural person behind the request
- The role and authorization context that was in effect
- The reference databases checked
- The data classification applied to the prompt
- The policy version that governed the decision
- The decision outcome (approve, deny, refer, modify)
- A timestamp with sufficient precision to correlate across systems
- A tamper-evident integrity control and retention policy
The record must be correlated with the credit-decision application and retained through the relevant review period. A separate evidence store reduces the chance that a production incident leaves the reviewer with an incomplete record.
DeepInspect
This is the architecture DeepInspect was built to provide for the routed part of the workload. DeepInspect sits at the HTTP AI request boundary between credit-decision applications and the LLM or model APIs they call. Every routed request is evaluated against per-route and per-role policies using the identity context the application supplies. PII is detected and classified, then the proxy commits an audit record before the model response returns.
The Article 12 fit is strongest where the model request actually passes through the proxy. The gateway does not capture a local scoring calculation, a reference-database query, or a human override that bypasses its HTTP route. Pair the routed-request record with application and case-management evidence to reconstruct the complete credit decision.
The Annex III date is 2 December 2027. A bank that starts joining request, model, policy, and human-review evidence now has time to test the record before a competent authority asks for it. Book a demo today.
Beyond Article 12
The same evidence discipline helps with adjacent credit-scoring obligations. NIST AI RMF gives US teams a voluntary framework for governing and measuring AI risk. GDPR Article 22, the Equal Credit Opportunity Act, and Regulation B create separate requirements around automated decisions, adverse action, and fair lending. Keep the legal analysis for each regime distinct rather than treating a single gateway log as a complete compliance record.
For related implementation detail, see the EU AI Act Article 12 logging guide, AI audit-log immutability, and GDPR Article 22 automated decisions.
Frequently asked questions
- Does the Annex III classification apply to alternative data credit scoring?
Yes. The Annex III, point 5(b) language refers to "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score." The classification turns on the purpose of evaluating creditworthiness, not on the data source. Alternative data scoring (bank transaction analysis, employment verification AI, rental history scoring) used to evaluate creditworthiness falls under the same classification.
- What about credit decisions for small businesses?
The Annex III text refers to natural persons. Business credit decisions for legal entities fall outside the literal scope. The exception is sole proprietorships and certain other unincorporated business forms where the credit decision attaches to the natural person rather than a corporate entity. The classification analysis turns on the legal structure of the borrower.
- How does this interact with the GDPR Article 22 automated decision-making rules?
GDPR Article 22 prohibits decisions based solely on automated processing that produce legal or similarly significant effects, unless an exception applies. Credit decisions typically rely on the contract-necessity exception or explicit consent. The EU AI Act Article 12 logging applies on top of the GDPR Article 22 requirements. The same per-decision audit record produced for Article 12 supports GDPR Article 22 documentation of the human-intervention requirement.
- What is the deadline for credit scoring AI specifically?
Regulation (EU) 2026/1744 sets 2 December 2027 as the application date for the Annex III high-risk-system requirements. Check the consolidated EUR-Lex text and the system's placing-on-the-market facts with counsel before setting a programme deadline.
- What about model risk management requirements that already apply to credit decisions?
The EU AI Act sits alongside existing model risk management requirements under the EBA Guidelines on internal governance, the ECB's TRIM exercise, and national regulator expectations. The architectural fix for Article 12 produces audit records that also satisfy model risk management documentation requirements. The two regimes converge on the per-decision evidence layer.