AI Credit Scoring for Sole Traders and SMEs: Is It High-Risk Under the EU AI Act?

What Annex III says, and where sole traders and SMEs sit

Annex III lists as high-risk the AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with an exception for systems used to detect financial fraud. The recitals explain the reasoning: these systems determine people's access to financial resources or essential services such as housing, electricity and telecommunication services, and they may lead to discrimination and perpetuate historical patterns of discrimination.

The wording refers to natural persons. It does not mention sole traders or incorporated SMEs by name. A sole trader trades in their own name and is a natural person, so a model that scores a sole trader's creditworthiness falls within the wording. An incorporated SME is a legal entity, and the Annex III text does not on its face cover it. Whether a given business-lending use case still reaches natural persons, for example through assessment of an individual owner, is a legal question that compliance teams should settle with counsel and record.

The Commission states that risk classification is based on the intended purpose of the AI system, and that a system is high-risk if it is intended to be used for an Annex III use case. That makes classification a per-use-case decision. A lender running one scoring model across consumers, sole traders and incorporated SMEs should not assume a single answer covers all three.

Exceptions and edge cases that decide classification

Three provisions shape the outcome in practice.

The fraud-detection exception is narrow. The Annex III exception applies to systems used for the purpose of detecting financial fraud. The recitals add that AI systems provided for by Union law for detecting fraud in the offering of financial services, and for prudential purposes to calculate capital requirements of credit institutions and insurance undertakings, should not be considered high-risk. A scoring model that also produces a fraud signal does not inherit the exception unless its purpose is fraud detection.

The Article 6 derogation is conditional. An Annex III system is not considered high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making. Our analysis is that a scoring output that feeds a lending decision is hard to present as non-influential. Any team relying on the derogation should document why.

Profiling removes the derogation. An Annex III system that performs profiling of natural persons is always considered high-risk. Credit scoring of an individual will usually involve profiling, so this edge case rarely helps a lender.

Obligations that follow and the timeline

Once a use case is high-risk, providers must subject the system to a conformity assessment before placing it on the EU market or putting it into service. A risk management system must be established, implemented, documented and maintained as a continuous, iterative process across the system's lifecycle, with regular systematic review and updating. High-risk systems must technically allow automatic recording of events over their lifetime, at a level of traceability appropriate to the intended purpose. The Commission also lists risk assessment and mitigation, high-quality datasets to minimise discriminatory outcomes, and robustness, cybersecurity and accuracy among the high-risk obligations.

On timing, the high-risk provisions were originally due to apply on 2 August 2026. The co-legislators reached a provisional agreement on 7 May 2026 under the Digital Omnibus on AI to delay them: 2 December 2027 for stand-alone high-risk systems, which is where a credit scoring system would normally sit, and 2 August 2028 for systems embedded in products. As of November 2026, the Commission's AI Act page states that high-risk obligations start on 2 December 2027. Because the dates have moved once, programme plans should track adoption of the amendment before fixing milestones.

Lenders will often be deployers rather than providers. The two roles carry different duties, so each scoring use case should record which role the organisation holds.

What can be enforced at runtime and what cannot

Not every obligation can be met in the AI execution path. Runtime controls act on individual interactions and tool calls. Several obligations sit before deployment or in the organisation. Mapping each one avoids claiming runtime coverage that does not exist.

• Automatic event recording and traceability: Partly runtime. The system must technically allow event recording, and per-interaction evidence of the controls applied can be produced as calls occur. The full list of required events should be checked against the legal text.
• Human review of consequential outputs: Partly runtime. An escalation step can hold an interaction for human approval. Reviewer competence, authority and procedure are organisational design.
• Data handling in individual requests: Runtime. Policy can allow, redact or block specific data in a given interaction. This does not address the quality of training datasets.
• Risk management system: Organisational. It is a lifecycle process with ownership and a review cadence, not a per-interaction control.
• Conformity assessment: Pre-deployment. It is completed before the system is placed on the market or put into service.
• Dataset quality and bias mitigation: Pre-deployment and governance. Fairness monitoring belongs here because discrimination risk is the stated reason credit scoring is high-risk.

Runtime enforcement and evidence in the execution path

Policy written in a document does not show what an AI system was allowed to do on a particular scoring request. Trussed enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, or escalate for human approval. Enforcement happens at runtime, not through review after the fact, and it applies to individual interactions and tool calls.

That enforcement generates continuous, audit-ready evidence, mapped to the EU AI Act among other frameworks. For a lender, the practical value is being able to show a regulator or auditor what a scoring workflow was permitted to do and what it did on a given request. Trussed does not replace conformity assessment, the risk management process or dataset governance, which remain with the provider and deployer. Deployment is self-managed in the customer cloud, with configurable retention and data residency.