EU AI Act Annex III December 2027 compliance plan for banks

What changed, and what did not

Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, amends the AI Act. The Commission states it entered into force on 27 July 2026. It applies the high-risk rules from 2 December 2027 for systems classified high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems under Article 6(1) and Annex I. The original 2 August 2026 date for these obligations no longer applies.

The mechanism also changed during negotiation. The Commission first proposed shifting the timeline by up to 16 months, with the rules starting once it confirmed that the needed standards and tools were available. The May 2026 provisional agreement replaced that floating start with fixed dates. The Commission ties the delay to late availability of standards and to the time needed to set up competent authorities in Member States.

For planning, this matters in two ways. The date is now fixed, so teams no longer need to wait for a Commission trigger. And nothing in the delay narrows scope. A bank that treated the proposal as a reason to pause has the same obligations, with a clearer deadline. What remains open is detail: the Commission's classification guidelines are still in draft, and the amending text refers to delegated acts that could change the Annex III list.

Start with an Annex III use-case inventory

Classification is the work that every later step depends on. AI systems referred to in Annex III are considered high-risk. A derogation applies where a system does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision making. An Annex III system that performs profiling of natural persons is always considered high-risk, so the derogation is unavailable for it. A provider who considers an Annex III system not high-risk must document that assessment before the system is placed on the market or put into service.

For a bank, the inventory should cover credit-related systems, including creditworthiness assessment and credit scoring of natural persons, and the models and tools that feed their outputs into decisions. Check each against the Annex III wording itself rather than against a general description of lending AI. Include vendor-supplied and embedded models, not only those built in-house.

For each system, record the intended purpose, whether the bank acts as provider or deployer, whether it profiles natural persons, whether its output materially influences a decision, the classification outcome, the reasoning and a named owner. That record is audit evidence in its own right. Role matters because some obligations attach to deployers. Deployers of high-risk systems referred to in points 5(b) and (c) of Annex III must perform a fundamental rights impact assessment before deployment, and Recital 96 names banking or insurance entities as examples of such deployers.

Run the gap assessment against existing model risk management

Most banks already operate a model inventory, validation, monitoring and change control. The task is to test that practice against the Act's requirements for each in-scope system, not to build a parallel programme. The requirement areas to cover are risk management, data governance, record-keeping and logging, human oversight, accuracy and robustness, and post-market monitoring.

Article 9 is the clearest anchor. The risk management system must be a continuous, iterative process planned and run throughout the system's lifecycle, with regular systematic review and updating. Testing must be carried out against prior defined metrics and probabilistic thresholds appropriate to the intended purpose. A useful first question is whether your validation and monitoring artefacts are tied to the intended purpose of each system as deployed, or only to the model in isolation.

Several further questions follow. Can you show how a human reviewer was able to intervene, and when one did? Can you reconstruct what a system did on a given date, not only how it was validated? Does monitoring continue after deployment with defined thresholds and an escalation path? Where the answer is no, record the gap, an owner and a remediation approach. Read the full text of the record-keeping, logging, human oversight and post-market monitoring articles when scoping fixes, because the design details sit there.

Decision points: build now or wait

Some work is safe to start immediately because it holds under any plausible change. Classification, role assignment, ownership, documentation and evidence capture fall into this group. None depends on final standards, and all of it will be asked for by an examiner or auditor regardless of how a guideline is finalised.

Other decisions should be tied to milestones. Final Commission classification guidelines could shift borderline calls, so mark every derogation-based conclusion for review when they are published. Any delegated act amending Annex III could add or change use cases, so keep the inventory process running rather than treating it as a one-time exercise. Standards availability was the stated reason for the delay, so avoid hard-coding detailed technical choices that a later standard might contradict.

A practical rule: commit now to what the evidence must show, and defer how it is formatted. Decide the log schema and retention periods early so records begin accumulating, but keep the structure easy to extend. A plan built this way does not need rewriting when a milestone moves. It needs a review.

Runtime enforcement and evidence worth putting in place early

Examiners will still expect a bank to show what an AI system was permitted to do and what it did. Pre-deployment validation answers part of that. Records produced at the point of execution answer the rest, and they take time to accumulate, which is the main argument for starting before 2027.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Policy is enforced at runtime, not reviewed after the fact: an interaction or tool call is allowed, redacted, blocked, rate limited or escalated for human approval. That enforcement produces audit-ready evidence, mapped to the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Trussed has run continuously in production in a regulated enterprise for more than 18 months, and insurance is where it is deepest.

The limits matter for scoping. Runtime enforcement covers individual interactions and tool calls. It does not provide transaction-level governance or end-to-end tracing of agentic workflows, and it does not replace classification, model validation, fundamental rights impact assessment or the bank's own accountability. It supplies one input, evidence of AI behavior and human escalation, to a compliance programme that the bank still has to own.