EU AI Act Annex III for US insurers and banks
The EU Artificial Intelligence Act — Regulation (EU) 2024/1689 — entered into force on 1 August 2024 and phases in over several years. US firms frequently assume it is a European problem. It is not, for the same reason GDPR was not: the Act has extraterritorial reach. Article 2 extends it to providers and deployers established outside the Union where the output produced by the AI system is used in the Union. A US insurer or bank whose model scores, prices, or decides for customers in the EU is within scope, regardless of where the model runs.
The risk tiers, and why Annex III is the one that matters
The Act sorts AI systems into four tiers: prohibited practices (Article 5), high-risk, limited-risk with transparency duties, and minimal-risk. The high-risk tier is defined two ways — systems that are safety components of regulated products (Annex I), and systems used in the specific use cases enumerated in Annex III. For financial services, two Annex III entries are decisive, both in its point 5 on access to essential private services.
- AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score — with a carve-out for systems used to detect financial fraud. This squarely covers consumer credit and loan-underwriting models.
- AI systems intended for risk assessment and pricing in relation to natural persons in the case of life and health insurance. This squarely covers life-and-health underwriting and pricing models.
A genuine scope nuance — flag for counsel
Annex III point 5 names life and health insurance risk assessment and pricing explicitly. It does not, on its face, enumerate property and casualty lines the same way, and creditworthiness checks performed purely to detect fraud are carved out. Whether a given P&C pricing model, or a hybrid underwriting system, is high-risk can turn on facts and on the Article 6(3) exception for systems that do not pose significant risk. Treat the line-of-business boundary and the 6(3) self-assessment as questions for EU regulatory counsel, not as settled by this article.
What high-risk classification obligates — Articles 9 through 15
Once a system is high-risk, Chapter III, Section 2 of the Act imposes a stack of requirements on the provider. These are the obligations a US firm has to be able to evidence.
- 1Article 9 — a risk-management system established, implemented, documented, and maintained across the lifecycle as a continuous, iterative process.
- 2Article 10 — data and data governance: training, validation, and testing datasets that are relevant, sufficiently representative, and examined for bias, with attention to the possibility of discriminatory outcomes.
- 3Article 11 and Annex IV — technical documentation drawn up before the system is placed on the market and kept up to date, containing the specific elements Annex IV enumerates.
- 4Article 12 — automatic recording of events (logs) over the system's lifetime, with traceability appropriate to the intended purpose.
- 5Article 13 — transparency and provision of information to deployers, sufficient for them to interpret output and use the system appropriately.
- 6Article 14 — human oversight: the system designed so natural persons can effectively oversee it, including the ability to intervene, to interpret output, and to decide not to use it or to override it.
- 7Article 15 — appropriate levels of accuracy, robustness, and cybersecurity, with the relevant metrics declared.
Deployers — the firms that use a high-risk system rather than build it — carry their own duties under Article 26, including operating the system per its instructions, assigning competent human oversight, monitoring operation, and keeping the automatically generated logs they control. A US bank that licenses a credit-scoring model is a deployer of it; a US insurer that builds its own life-underwriting model is the provider of it. Many firms are both, for different systems, and the obligations differ accordingly.
The timeline that sets the deadline
The Act's obligations switch on in stages from the 1 August 2024 entry into force. The prohibitions in Article 5 and the AI-literacy duty applied from 2 February 2025. Obligations for general-purpose AI models and the governance provisions applied from 2 August 2025. The pivotal date for financial-services firms is 2 August 2026, when the bulk of the high-risk requirements — including the Annex III obligations described above — become applicable. (Systems that are high-risk by virtue of being safety components of Annex I products get a longer runway, to 2 August 2027.) For an institution whose creditworthiness or life-and-health pricing models touch EU customers, the 2026 date is the one to plan against, and the documentation, logging, and oversight machinery has to be standing before it, not after.
Why the deadline is unforgiving: the penalty tier
The Act backs its obligations with penalties calibrated to be felt by large firms. Article 99 sets the headline exposure for non-compliance with most obligations — including the high-risk requirements relevant here — at up to 15 million euros or up to 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. Breaching the Article 5 prohibitions carries a higher ceiling, up to 35 million euros or 7% of worldwide turnover. Supplying incorrect, incomplete, or misleading information to authorities sits at a lower tier. The turnover basis is what makes this concentrate the mind: for a large insurer or bank, a percentage-of-global-turnover penalty is a board-level number, and it attaches to the same documentation and oversight failures that are otherwise easy to defer.
Provider and deployer keep different evidence
Because a single institution is often a provider of some systems and a deployer of others, it helps to be precise about which evidence each role has to hold, since an audit will ask the role-appropriate question.
- As a provider (you built or substantially modified the system, or put it on the market under your name): the Annex IV technical documentation, the Article 9 risk-management file, the Article 10 data-governance and bias-examination record, the Article 12 logging design, the Article 13 instructions for deployers, the Article 14 human-oversight design, and the Article 15 accuracy/robustness/security metrics — plus the conformity-assessment record and EU declaration of conformity.
- As a deployer (you use a high-risk system built by someone else): evidence under Article 26 that you operate it per the provider's instructions, that you assigned competent human oversight, that you monitor its operation and report serious incidents, and that you retain the automatically generated logs under your control for the period the Act specifies.
The general-purpose-model wrinkle
Many financial-services AI features are now built on top of general-purpose AI models. The Act regulates those GPAI models under their own regime (Chapter V), with obligations that fall primarily on the model provider — but when you fine-tune or build a high-risk system on top of one, you may take on provider obligations for the resulting high-risk system even though you did not train the base model. The practical consequence is a lineage problem: you have to be able to document which base model your high-risk system depends on, and what you changed, to know which obligations are yours.
How Pratvi helps
Pratvi AI is structured around the Annex III high-risk obligations. The AI Model Inventory provides the risk classification and the technical-documentation backbone Articles 11 and Annex IV require, capturing purpose, lifecycle state, and the foundation-model lineage that determines whether provider or deployer obligations attach to a given system. The Compliance Engine runs conformity-assessment workflows against the EU AI Act high-risk requirement set — Articles 9 through 15 — and performs the per-model gap analysis that tells you where you stand before the August 2026 date. The Confidence & Verification module operationalizes the Article 14 human-oversight mandate, routing decisions to auto-approve, flag-for-review, or human-required and surfacing model disagreements for intervention. And the Immutable Audit Trail delivers the Article 12 event logging with tamper-evident traceability over the system's lifetime.
This article is educational and does not constitute legal advice. Regulatory requirements change and apply differently by jurisdiction and facts — confirm specifics with qualified counsel. References to Pratvi AI modules describe platform capability and do not imply certification.