AI Credit Limit Increase Decisioning: High-Risk Classification Under the EU AI Act

What Annex III says, and what it leaves open

Annex III of Regulation (EU) 2024/1689 lists AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud. Recital 58 explains the reasoning: such systems determine access to financial resources or essential services, and they may lead to discrimination or perpetuate historical discrimination patterns. The recital also says that AI systems provided for by Union law for detecting fraud in the offering of financial services, and for prudential calculation of capital requirements of credit institutions and insurers, should not be considered high-risk.

The wording turns on intended purpose. It does not name credit limit increases, pre-approved offers or fraud-adjacent signals. Classifying those cases therefore means reading the Annex III text against what each model is designed and documented to do. That is an interpretation, and a position worth confirming with counsel and recording in writing.

The Commission publishes guidelines to help providers and deployers assess whether a system is high-risk, with practical examples. Use them for borderline cases, and keep your own reasoning on file regardless of what they say.

Working readings for common limit-increase scenarios

The readings below are a practitioner's interpretation of the Annex III text, not settled guidance. The deciding question in each case is whether the system is intended to evaluate creditworthiness or establish a credit score of a natural person. The label on the product matters less than the function the model performs.

• Model that decides whether to raise a customer's limit: Likely in scope. Deciding on additional credit generally involves assessing the person's capacity to repay, which is evaluating creditworthiness.
• Pre-approved offer model: Depends on intended purpose. If eligibility turns on a creditworthiness assessment or score, treat it as likely in scope. If it only selects a marketing audience, document why.
• Model used solely to detect financial fraud: The Annex III exception is worded for systems used for the purpose of detecting financial fraud. Keep the documented purpose and the actual use aligned.
• Model that mixes fraud signals with credit evaluation: May not fit the exception cleanly, because the credit-evaluation function remains. This is an inference from the wording, so assess the credit-evaluation component separately.

The Article 6(3) derogation and the timing question

Article 6(3) provides that an Annex III system is not considered high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision making. The derogation does not apply where the system performs profiling of natural persons, because such a system always counts as high-risk. Credit decision models usually build a profile of an individual from their data, so relying on the derogation for a limit-increase model is difficult to sustain. If you do rely on it, record the reasoning and the profiling analysis.

On timing, Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026. As of November 2026, it sets Chapter III application for systems classified as high-risk under Article 6(2) and Annex III at 2 December 2027, replacing the original date of 2 August 2026. The stated reasons are delayed standards, common specifications and guidance, and delayed establishment of national competent authorities. The Commission's earlier proposal had tied application to the availability of standards and tools. The adopted text uses fixed dates instead, so planning can be anchored to a calendar date rather than a readiness trigger.

What each obligation asks for, and where runtime evidence fits

Once a system is high-risk, the obligations split between what the system must be able to do, what the provider must do, and what the deployer must do. Runtime enforcement bears on only part of that. Evidence from enforcement supports documented governance but does not replace it.

• Article 9: risk management: A documented, continuously updated lifecycle process with regular systematic review. This is organizational. Runtime evidence can inform reviews, but it does not supply the process.
• Article 12: automatic logging: The system must technically allow automatic recording of events relevant to traceability for its intended purpose. Providers keep logs under their control for at least six months, subject to data protection law. Define which events matter for a limit-increase decision against that purpose.
• Article 14: human oversight: The system must be designed so natural persons can effectively oversee it, with appropriate human-machine interface tools. An escalation step in the decision path is one way to show oversight was exercised. Who oversees, and with what authority, remains an organizational decision.
• Article 26: deployer duties: Deployers take appropriate technical and organisational measures to use the system in accordance with its instructions for use. Adherence to those instructions and the supporting documentation sit with the deployer.
• Conformity assessment: A provider obligation before the system is placed on the EU market or put into service. It sits outside any runtime control.

Where runtime policy enforcement fits

Retention design needs care. A six-month minimum for provider-controlled logs has to be reconciled with data protection law, so decide what personal data the evidence contains, how long it is kept and where it resides. Redaction before evidence is written is one practical way to reduce that exposure.

Trussed enforces policy in the execution path, so allow, redact, block, rate limit and escalate-for-human-approval decisions are enforced at runtime, not reviewed after the fact. The scope is individual interactions and tool calls across models, agents, tools and MCP servers. Each enforcement decision generates audit-ready evidence mapped to the EU AI Act, among other frameworks. For a limit-increase workflow, that can show an auditor what an AI component was permitted to do, what was redacted or blocked, and when a human approval step was triggered. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

The limits are as important as the capabilities. This evidence does not classify your system, run your Article 9 process, perform a conformity assessment or assign accountable overseers. It does not replace the provider's Article 12 logging capability within the high-risk system itself. Tooling does not confer compliance. It gives the documented governance something concrete to point to.