EU AI Act: What Financial Firms Must Actually Do Before August 2, 2026

There is a version of EU AI Act compliance that looks good in a board presentation. Risk register updated. Governance council established. Policy documents drafted. A consultant engaged to produce a gap analysis.

And there is the version regulators will ask for on August 3, 2026.

Those two versions are not the same document. This article is about the second one.

The EU AI Act is not a framework you comply with by writing better policies. It is a technical regulation that requires operational evidence — automated logs, tamper-evident records, documented conformity assessments, human oversight mechanisms that actually work, and an EU database registration that must be filed before the deadline, not after. For financial institutions, the gap between where most firms are today and where the regulation requires them to be is significant, the timeline is short, and the penalties — up to €35 million or 7% of global annual turnover — are calibrated to produce board-level attention at any company size.

This article explains, article by article, what the law actually requires, which financial AI systems are in scope, and what "done" looks like for each obligation.

First: Is Your AI System In Scope?

Before any compliance work begins, a firm needs to know which of its AI systems the Act applies to. The EU AI Act uses a risk-based classification system. Most of what financial firms have built or deployed falls into one of two categories.

Prohibited practices — already in force since February 2, 2025. These are banned outright: social scoring systems, AI that manipulates human behavior through subliminal techniques, real-time biometric identification in public spaces (with narrow law enforcement exceptions), and workplace emotion recognition systems. If your firm has any of these, they were already non-compliant fourteen months ago.

High-risk AI systems — the category that governs most financial AI. Under Annex III, high-risk systems in financial services include AI intended to evaluate the creditworthiness of natural persons or establish their credit score, and AI intended for risk assessment and pricing in relation to natural persons in the case of life and health insurance.

The full list of high-risk financial AI is broader than most firms realize. It includes credit decisioning, fraud detection, trading algorithms, risk assessment, identity verification, portfolio recommendations, and transaction monitoring — every AI system touching EU customers or data.

One common misconception is that only the firm that built the AI system is responsible. The Act distinguishes between providers (who build and place AI systems on the market) and deployers (who use AI systems in their operations). Both carry obligations. A hedge fund that licences an AI trading system from a vendor is a deployer — subject to Article 26 obligations — even if it built nothing itself. A bank that fine-tunes a foundation model on its proprietary data has crossed from deployer to provider, and carries the full provider obligation set. This distinction requires legal clarity before any technical work begins.

The regulation's extraterritorial reach mirrors GDPR. Any organization, regardless of location, must comply if its AI systems are used within the EU or produce outputs that affect EU residents. A US-based company using AI for loan approvals that serves European customers falls within scope, even if the AI models run on servers outside Europe.

The Seven Articles That Define High-Risk Compliance

For high-risk AI systems, Articles 9 through 15 define the core technical obligations. From August 2, 2026, organizations deploying high-risk AI systems must demonstrate full compliance with Articles 9 through 49 — including documented, ongoing risk management systems under Article 9, training data governance under Article 10, complete technical documentation under Article 11 and Annex IV, automatic logging of system events under Article 12, transparency obligations under Articles 13 and 14, human oversight mechanisms under Article 14, and accuracy, robustness, and cybersecurity controls under Article 15.

Each of these is worth examining in detail, because each one has a specific technical implementation requirement that a policy document alone cannot satisfy.

Article 9 — Risk Management System

Article 9 requires a documented, continuous risk management system for every high-risk AI system. Not a one-time risk assessment. Not a quarterly review. A system that operates throughout the AI system's entire lifecycle.

In practice this means: a documented process for identifying and assessing risks before deployment, a set of residual risk controls, a monitoring mechanism that detects when risks materialise during operation, and a defined escalation path when they do. The risk management system must be updated when the AI system is substantially modified or when post-market monitoring reveals new risks.

For financial firms, this intersects with existing model risk management frameworks — MaRisk in Germany, SR 11-7 in the US context, and the EBA's guidelines on internal governance. The AI Act introduces horizontal obligations that broadly apply across all high-risk AI systems, including those deployed in creditworthiness assessment or premium calculation for health or life insurance — these requirements exceed and nuance familiar requirements of banking and consumer credit law.

The key compliance gap for most firms: existing model risk management frameworks validate models at deployment. Article 9 requires ongoing risk management that runs continuously. The systems and processes that satisfy one do not automatically satisfy the other.

Article 10 — Data Governance

Article 10 governs the training, validation, and testing data used in high-risk AI systems. It requires that data sets be relevant, sufficiently representative, and free from errors and gaps. It requires that data governance practices be documented. And critically, it requires examination of training data for possible biases.

For financial institutions, this has direct implications for any AI system trained on historical data — credit scoring models trained on historical lending decisions, fraud detection models trained on historical transaction patterns, and trading models trained on historical market data. Training data must be relevant, representative, and free from bias. If your credit scoring model was trained on historically discriminatory lending data, you're violating AI Act requirements regardless of current performance.

The practical challenge: bias assessments for financial AI are not the same as bias assessments for general-purpose AI. Financial data carries structural biases that reflect decades of discriminatory lending, redlining, and differential access to credit. Demonstrating compliance with Article 10 for a credit scoring model requires documented methodology for identifying those biases, demonstrated corrective steps, and ongoing monitoring for bias drift as the model continues to operate on live data.

Article 11 — Technical Documentation

Article 11 requires that high-risk AI systems have complete technical documentation drawn up before they are placed on the market or put into service. Annex IV specifies what that documentation must contain: a general description of the system, a description of its components and development process, information about training methodologies and datasets, performance metrics, known limitations, and the risk management measures applied.

The compliance failure that appears most commonly in audits is not missing documentation — it is documentation that has drifted from the actual system. When legal documentation is not derived from the actual system state, it drifts. In many AI systems, especially in financial services, the documentation and system specifications diverged within 12 months of deployment.

Documentation-as-code is the practice that addresses this: technical documentation that is generated from or linked to the actual system artefacts — model cards, training run logs, data lineage records — rather than written separately by a compliance team who describes the system from memory. When the system changes, the documentation changes with it. When it does not, the change is detected.

Article 12 — Automatic Logging

This is the article that most financial firms are furthest from meeting — and the one with the most direct technical implementation requirement.

Article 12 requires automatic logging capabilities enabling traceability throughout the system lifecycle, capturing event logs identifying risks and substantial modifications during deployment.

The regulation specifies that the logging system must operate automatically — it cannot depend on manual data entry. It specifies that logs must enable traceability, meaning they must capture enough information to reconstruct what the AI system did and why. And critically, it requires that logs be tamper-resistant to ensure auditability.

This last requirement is where most current logging implementations fall short. A log stored in a writable database is not tamper-resistant, regardless of the access controls around it. A database administrator with sufficient privileges can modify records without detection. The regulation's requirement for tamper-resistance has a specific technical meaning: the logging architecture must make modification detectable — not merely difficult.

Article 12 requires comprehensive decision logging. GDPR requires deletion when purpose ends. SOC 2 and SOX carry their own retention windows. These three requirements conflict. The logging architecture has to satisfy all three from the start, using crypto-shredding to handle GDPR erasure while preserving log structure for AI Act and financial regulation compliance.

The intersection of Article 12 with existing financial regulation creates additional complexity specific to financial institutions. SEC Rule 17a-4 requires seven-year retention for certain records. FINRA Rule 4370 requires audit trails for AI-assisted communications. MiFID II Article 25 requires communication recording. A logging architecture for financial AI must satisfy all of these simultaneously — not sequentially, and not with separate systems bolted together.

Article 13 — Transparency

Article 13 requires that high-risk AI systems be designed to enable deployers to understand what the system is doing. This means instructions for use that explain the system's intended purpose, its level of accuracy, its known limitations, and how to interpret its outputs correctly.

For financial AI, this has a specific compliance implication around explainability. A credit decision supported by an AI system must be explainable to the deployer in terms they can act on. A trading signal generated by an AI system must be traceable to the inputs and parameters that produced it. Far from being a black box, each model's decision logic must be visualised for risk officers and regulators. Compliance teams must be able to trace every trade signal to its data source and algorithmic reasoning.

Explainability is not the same as interpretability. A model does not need to be intrinsically interpretable — it needs to produce explanations that a human supervisor can evaluate and act on. Post-hoc explanation methods (SHAP, LIME, and similar approaches) can satisfy Article 13 requirements for many financial models, provided those explanations are generated automatically, logged alongside decisions, and made available to supervisors on demand.

Article 14 — Human Oversight

Article 14 is one of the most operationally demanding articles in the Act, and one of the most misunderstood.

Article 14 embeds a "human-in-command" philosophy requiring that high-risk AI be designed to allow effective human supervision during use. This is not mere human presence — it is meaningful oversight capability. Effective oversight demands that human supervisors can understand system limitations, detect anomalies, avoid automation bias, and intervene or interrupt via stop buttons, override mechanisms, or the ability to prevent outputs from taking effect until human review confirms appropriateness.

For financial institutions, automation bias is a specific documented risk. Traders and analysts who work alongside AI systems consistently over-trust AI outputs and under-apply independent judgement, particularly when the AI system has a strong recent track record. Article 14 requires that systems be designed to counteract this tendency — not merely to provide override buttons that supervisors rarely use.

Article 14 requires deployers of high-risk AI systems to assign responsibility for operational oversight of the performance of each system to specific individuals with appropriate training.

Named individuals. With appropriate training. Documented. For every high-risk AI system in operation. This is an organizational requirement, not just a technical one. A compliance gap here is not fixed by logging more data — it requires changes to job descriptions, training programs, and accountability structures.

Article 15 — Accuracy, Robustness, and Cybersecurity

Article 15 requires that high-risk AI systems achieve appropriate levels of accuracy for their intended purpose, maintain consistent performance under unexpected or adversarial conditions, and resist cybersecurity attacks specific to AI systems.

Robustness requires consistent performance even with unexpected inputs or changing conditions. Cybersecurity encompasses resilience against adversarial attacks like prompt injection, data poisoning, and model extraction attempts.

For financial AI, model drift is the most common Article 15 compliance failure in practice. A credit scoring model trained on pre-2020 data and deployed continuously has been operating on distribution-shifted inputs for six years. Its accuracy metrics at deployment are not its accuracy metrics today. Article 15 requires that accuracy be maintained throughout the lifecycle — which means continuous monitoring for drift, defined thresholds for when retraining is triggered, and documented evidence that those thresholds were respected.

AI-specific cybersecurity threats — data poisoning, adversarial examples, model extraction — require controls that most financial institution security programs have not yet incorporated. Standard penetration testing and vulnerability scanning do not cover these attack vectors. Red team testing specifically designed for AI systems is the emerging standard, and for high-risk financial AI it is moving from best practice to regulatory expectation.

The Conformity Assessment and EU Database Registration

Articles 9 through 15 define what a compliant high-risk AI system looks like. Before deploying it, a provider must also complete a conformity assessment and register the system in the EU AI database.

For most financial AI systems, self-assessment is permitted — the provider conducts its own evaluation, documents the results, prepares an EU Declaration of Conformity, and affixes CE marking. Biometric identification systems and AI embedded in certain regulated products require third-party assessment by a notified body.

Only 18% of organizations have fully implemented AI governance frameworks despite 88% using AI operationally. For the 82% that have not, the conformity assessment is not a documentation exercise that can be completed in a week. It requires documented evidence that each of Articles 9 through 15 is satisfied — evidence that in most cases does not yet exist and must be built before the assessment can be completed.

EU database registration must be completed before the system is deployed or continues to be used after August 2, 2026. It is not an after-the-fact filing.

The Intersection With Existing Financial Regulation

Financial institutions face a compliance landscape where the EU AI Act does not replace existing regulation — it layers on top of it.

Financial AI systems must comply with the AI Act, GDPR, Anti-Money Laundering Directive, MiFID II, and sector-specific guidance from the European Banking Authority and European Securities and Markets Authority.

DORA (Digital Operational Resilience Act), which has been in force since January 2025, adds ICT risk management, incident reporting, and resilience testing requirements that overlap significantly with Article 9 (risk management) and Article 15 (robustness and cybersecurity). Firms that have built DORA compliance infrastructure have a useful foundation for Article 9 and Article 15 — but the overlap is not complete. DORA focuses on operational resilience of ICT systems. The AI Act focuses on the risk profile of AI decision-making. These are related but not identical obligations.

The MiFID II communication recording requirement creates a specific intersection with Article 12 logging. MiFID II requires that AI-assisted investment communications be recorded. Article 12 requires that AI system events be logged. A firm using an AI assistant to help draft client communications needs a logging architecture that satisfies both — capturing both the AI system's actions (Article 12) and the communication output (MiFID II) in a way that links the two.

What "Done" Looks Like — A Practical Checklist

The following is a minimum viable compliance checklist for a financial institution deploying high-risk AI. It does not substitute for legal advice specific to your jurisdiction and systems.

The Honest Assessment of Where Most Firms Are

The compliance failures that will appear in 2026 enforcement actions will not generally be organizations that tried and got the details wrong. They will be organisations that treated the AI Act as a documentation exercise, produced policy documents that describe systems that no longer exist, built logging that captures data no one can query, and assigned human oversight responsibility to people who received no training and have no authority to intervene.

The article that separates firms that pass regulatory scrutiny from those that do not is Article 12. Logging that is automatic, tamper-evident, queryable, and linked to real human identities is either there from the first request or it is not there at all. It cannot be reconstructed after the fact. The EU AI Act is explicit on this point: the audit trail must be created at the time of the event. There is no forensic reconstruction that recovers a missing log entry.

Over half of organizations still lack a basic AI inventory. Firms that do not know what AI systems they are running cannot complete a conformity assessment. Firms that cannot complete a conformity assessment cannot register in the EU database. Firms that are not registered and not compliant on August 2, 2026 are immediately subject to enforcement.

The timeline is what it is. The work is specific, technical, and operational. It cannot be delegated to a policy team. And it cannot start too early, because in almost every firm it has already started too late.

A Note on the Digital Omnibus

In November 2025, the European Commission proposed the Digital Omnibus package — a set of amendments that could, if adopted, extend the high-risk AI compliance deadline for Annex III systems from August 2, 2026 to December 2, 2027. The proposal is currently being examined by the European Parliament and the Council.

Prudent compliance planning treats August 2026 as the binding deadline. Organizations should not assume the extension will materialize. The Digital Omnibus is a legislative proposal — it requires negotiation, amendment, and formal adoption before it has legal force. As of April 2026, that process is ongoing and its outcome is uncertain. Planning around a potential extension that may not arrive is the compliance failure mode, not the compliance strategy.

Conclusion

The EU AI Act does not ask financial firms to govern AI better in principle. It asks for operational evidence that governance is working in practice — automated, continuous, tamper-evident, and linked to real human identities and real human oversight.

The gap between where most firms are and where the regulation requires them to be is not a gap in understanding. Most compliance teams understand the regulation. The gap is in implementation: the logging architecture that is not yet built, the bias assessments that are not yet completed, the oversight personnel who are not yet trained, the conformity assessments that are not yet documented.

August 2, 2026 is the date those gaps become enforcement risk. It is 113 days from the date this article was published.