EU AI Act vs EBA Loan Origination Guidelines: AI Credit Decision Controls Mapped

Why credit decisioning sits at the centre of both frameworks

The recitals of Regulation (EU) 2024/1689 state that AI systems used to evaluate the credit score or creditworthiness of natural persons should be classified as high-risk. The stated reasoning is that these systems determine access to financial resources or essential services such as housing, electricity and telecommunication services. The recitals also note that such systems may lead to discrimination between persons or groups, may perpetuate historical patterns of discrimination, or may create new forms of discriminatory impact. The Commission's own materials use credit scoring that denies someone a loan as an example of a high-risk use.

Recital 46 sets the consequence: high-risk AI systems should only be placed on the Union market, put into service or used if they comply with mandatory requirements intended to ensure they do not pose unacceptable risks to important Union public interests. Classification is therefore the entry point for the obligations.

The EBA Guidelines on loan origination and monitoring govern the same lending activity from the prudential side, with expectations on data and model governance, explainability, human involvement and ongoing monitoring. The two frameworks differ in vocabulary, scope and the bodies that oversee them. A compliance team ends up with two sets of terms for what is largely one operational question: what was the AI allowed to do, and what did it do, when this credit decision was made?

Timing: the application dates are in motion

As of November 2026, the Commission's Digital Omnibus on AI, proposed on 19 November 2025, would set fixed deadlines for the delayed application of high-risk AI rules. As described by the European Parliament's Legislative Train, these are 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk systems embedded in products. This is a proposal, so planning should treat the dates as subject to change.

The Commission has also published draft guidelines to help providers and deployers assess whether an AI system is high-risk, to be complemented in time by guidelines on compliance with the high-risk obligations. Institutions should confirm their role as provider or deployer for each credit-related AI use, because the role determines which obligations apply to them.

Control mapping: where each control operates and what it should evidence

The matrix below organises controls by the requirement themes both frameworks address: risk management, data governance, record-keeping, transparency, human oversight, accuracy and robustness, and ongoing monitoring. The "where it operates" distinction is an architectural view, not a statement about any specific article. Confirm each mapping against the primary texts with your legal and compliance advisers.

• Permitted actions per interaction: Runtime. Policy decides whether a model or agent may take a given action or call a given tool, and allows or blocks it. Evidence: policy version applied, the action requested and the allow or block outcome.
• Handling of personal and sensitive data: Runtime for what enters and leaves an interaction, by redaction. Evidence: what was redacted, under which policy, at what time. Lifecycle for training and test data, which needs separate data governance records.
• Human oversight of high-impact outputs: Runtime where a decision is escalated for human approval before it proceeds. Evidence: the escalation trigger, approver identity, decision and timestamp. Whether this meets the definition of oversight in either text needs checking against that text.
• Per-decision record-keeping: Runtime generation of a durable record for each enforced interaction. Evidence: a retrievable record linking policy, outcome and any human action. Retention periods should be set against the applicable requirements.
• Data and model governance, development, validation: Lifecycle. Owned by model risk, data and engineering functions before and between deployments. Evidence: dataset documentation, validation reports, approvals and change records. Runtime enforcement does not replace these.
• Accuracy, robustness and ongoing monitoring: Lifecycle, with runtime signals as inputs. Evidence: performance and bias testing results, monitoring reviews and remediation actions. Blocked or escalated interactions can feed monitoring but do not constitute it.

What runtime enforcement can and cannot cover

Runtime enforcement operates on individual interactions and tool calls. When an AI agent assembling a credit assessment requests applicant data, calls a scoring tool or proposes an outcome, a policy in the execution path can allow the step, redact fields, block it, or hold it for human approval. Because the decision is made at the moment of execution, the policy that applied and the outcome can be recorded for that specific step. That is a different property from reviewing outputs after the fact.

The limits matter as much. A runtime policy cannot make a poorly built model accurate, correct unrepresentative training data, or substitute for pre-deployment validation. Bias that originates in historical patterns, the concern the recitals raise, has to be addressed through data governance, model development and testing. Runtime control can constrain what a model is permitted to do with its output, and it can route consequential outputs to a person. It does not change how the model was built.

The human oversight control illustrates the boundary. Escalation for approval is something a runtime policy can enforce, and it produces a record of who approved what. Whether a reviewer has the competence, authority and information to meaningfully challenge the output is an organisational matter involving training, staffing and procedure, and it needs its own evidence.

Evidence for a single credit decision

Both frameworks are ultimately tested through evidence. A practical standard is to ask whether, for any one credit decision, the institution can show what the AI was permitted to do, what it did, and whether a human approved it. That requires linking several artefacts: the policy version in force, each enforced action and its outcome, any redaction applied, any escalation and the approver, and the final decision recorded in the lending system.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and generates continuous audit-ready evidence from that enforcement, mapped to the EU AI Act. That evidence covers what happened at the interaction and tool-call level. It does not cover model lineage, dataset provenance or transaction-level governance across tasks and agents, so lifecycle records for those must come from other processes.

Whichever tooling is used, define the evidence artefact per control before deployment, decide retention and data residency up front, and keep lifecycle and runtime records retrievable together. An auditor reading a decision record should not need to reconstruct the policy state from separate systems.