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?

The August 2, 2026 deadline applies to high-risk AI systems under Annex III. AI systems placed on the market before August 2, 2026 fall under a transition period under Article 111. New deployments after August 2, 2026 must comply from the start. Existing deployments must come into compliance during the transition period set by Article 111.

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.

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 systems used to evaluate the creditworthiness of natural persons or to establish their credit score as high-risk. The classification triggers a stack of obligations: Article 9 risk management, Article 10 data governance, Article 12 automatic logging, Article 13 transparency, Article 14 human oversight, and Article 26 deployer obligations. The high-risk system requirements take effect on August 2, 2026. Article 99 sets the penalty tier at €15 million or 3% of global annual turnover.

Most credit-scoring AI deployments in 2026 have no Article 12 architecture. The logs the bank or fintech produces today are application logs written by the credit decision system. The records lack the natural-person identification, policy state, and tamper-evidence that Article 12 expects.

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.

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.

The high-risk classification triggers the obligations in Title III, Chapter 2 of the Act. The articles that operate at the request layer are Articles 12, 13, 14, and 26.

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 specifies the log content: period of use, reference databases checked, input data leading to a match, and identification of the natural persons involved in result verification.

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 the instructions for use, assign human oversight to natural persons with the required competence and authority, monitor the system's operation, and retain the 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 architecture that satisfies Article 12 for credit scoring AI produces, for every model request, 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 cryptographic signature that prevents post-hoc modification

That record is independent of the credit decision application that made the request. It is committed before the model response returns to the application. It persists regardless of the application's runtime state.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between credit decision applications and the LLM or model APIs they call. Every request is evaluated against per-route, per-role policies using the identity context the application supplies. PII is detected and classified. Reference database calls are captured. The audit record is signed and tamper-evident, committed before the model response returns.

The Article 12 fit is structural. The recording is automatic because it is structural to the proxy's design. The recording covers the lifetime of the deployment because the proxy is the gate every request passes through. The records are detailed enough to reconstruct decisions because they capture identity, policy, and classification at the moment of evaluation.

If you are facing the August 2 EU AI Act deadline for credit-scoring AI and your architecture relies on application logs that the application controls, that readiness is incomplete. Book a demo today.

Beyond Article 12

The same architectural pattern satisfies adjacent obligations on credit scoring AI. NIST AI RMF identity and authorization framing applies to US deployments. Fannie Mae LL-2026-04 attaches AI governance requirements to mortgage-related credit decisions. DORA Article 28 applies to financial entities' third-party AI dependencies. The Equal Credit Opportunity Act and Regulation B in the US apply adverse action notice and fair lending considerations to AI-assisted credit decisions. The same per-decision audit record supports adverse action documentation.