Is an LLM That Drafts Credit Decision Rationales High-Risk Under the EU AI Act?

Classification follows system role, not model type

The AI Act's recitals state that AI systems used to evaluate the credit score or creditworthiness of natural persons should be classified as high-risk, because they determine access to financial resources or essential services such as housing, electricity and telecommunication services. The recitals also tie classification for stand-alone systems to intended purpose, the severity and probability of harm to fundamental rights, and use in specifically pre-defined areas. Nothing in that logic turns on whether the system is a large language model, a gradient-boosted scorecard or a rules engine.

For a rationale-drafting LLM, the question is therefore what the system does in the credit process. A model that scores applicants is plainly in scope. A model that writes text is a harder case, because its output is prose rather than a score. The analysis has to ask whether that prose affects the decision or only describes it.

Three roles are worth separating. In the first, the LLM's output feeds the decision, for example by summarising an applicant file that a decision-maker then relies on. In the second, the LLM drafts a rationale that a human reviews before it is issued, while the decision is made independently. In the third, the LLM produces an explanation after the decision is final, with no path back into decisioning. The closer the system sits to the first role, the weaker the case for exemption.

How the Article 6(3) derogation applies

Under Article 6(3), 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. The test is about influence on the outcome. A system does not escape high-risk status because its output is labelled a draft or a convenience.

One of the derogation conditions is directly relevant to review workflows. It covers a system intended to detect decision-making patterns or deviations from prior patterns that is not meant to replace or influence a previously completed human assessment without proper human review. The operative words are completed and proper. If drafts arrive before the assessment is finished, or if reviewers approve them without the time, competence or authority to change the outcome, the review is unlikely to carry the weight a derogation argument needs.

The practical consequence is that a human-in-the-loop step does not by itself decide the question. It is evidence, and its value depends on how it works in practice. A reviewer who sees only the draft and a approve button is in a different position from one who sees the underlying file, can edit the text and can reopen the decision.

Obligations if the system is high-risk, and the evidence they generate

High-risk systems must meet the requirements of the relevant Section, taking into account intended purpose and the generally acknowledged state of the art. Two requirements translate directly into evidence needs.

The first is event recording. High-risk systems must technically allow automatic recording of events over the lifetime of the system. Providers must keep the automatically generated logs to the extent they are under their control, for a period appropriate to the intended purpose and at least six months, unless other Union or national law, in particular data protection law, provides otherwise. For an LLM that handles applicant data, this means the retention rule has to be reconciled with data protection requirements, since prompts and outputs can contain personal data.

The second is human oversight and deployer conduct. The recitals say deployers should take appropriate technical and organisational measures to use high-risk systems according to the instructions for use, monitor their functioning and keep records as appropriate. People assigned to oversight need competence, AI literacy, training and authority. For a drafting workflow, that means defining who reviews rationales, what they are trained to look for and what they are empowered to do.

A useful design practice is to keep two kinds of evidence apart: what the system was permitted to do (policy) and what it actually did (interaction records). A regulator asking about a specific rationale will want both. Capturing inputs, outputs, the policy applied and any human approval per interaction is a design choice rather than a stated legal requirement, but it supports the recording and record-keeping expectations above.

Timing as of October 2026

The AI Act is in force. The Digital Omnibus on AI was proposed on 19 November 2025, and Parliament adopted its position in March 2026. As of October 2026, the Commission describes a political agreement under which the Annex III high-risk rules apply from 2 December 2027 and the rules for high-risk systems embedded in products apply from 2 August 2028.

Compliance teams should plan against 2 December 2027 for a creditworthiness-related system while tracking formal adoption and publication of the amending text. Classification work does not need to wait for that date. The facts that decide the outcome, namely role, influence and quality of review, are properties of the design, and they are cheaper to settle before deployment scales than after.

The Omnibus co-legislators also reinstated a simplified registration obligation for non-high-risk AI systems. A team relying on the derogation should record its basis and check whether that obligation applies.

Where runtime enforcement supports the evidence

Trussed does not determine classification and does not deliver compliance on its own. The classification decision, the provider and deployer analysis and the legal reasoning remain with the regulated enterprise. What Trussed supports is the operational layer once those decisions are made.

Trussed enforces policy in the execution path, across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. For a rationale-drafting workflow, a policy can allow a draft to proceed, redact personal data before it reaches the model or the output, block content that falls outside the permitted purpose, or escalate a draft for human approval. These are enforced at runtime, not reviewed after the fact. Because the same enforcement generates continuous audit-ready evidence mapped to the EU AI Act, a team can show what the system was allowed to do and what it did for a given interaction, including whether a human approved it.

Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which helps when log retention has to be reconciled with data protection rules. Evidence is generated per interaction. It does not describe model lineage or trace entire workflows end to end.