Know which of your systems are actually high-risk before you build a program around the wrong ones
Annex III of the EU AI Act lists specific high-risk use cases for financial services: creditworthiness assessment and credit scoring, and risk assessment and pricing for life and health insurance. Run every AI system you operate through the Annex III list specifically — not a general sense of "this feels high-stakes" — because the compliance burden that follows is substantial and you don't want to apply it to the wrong population of models.
So what: before you spend a quarter building an EU AI Act program, get your legal and compliance teams to produce a written Annex III applicability determination for each system, with the specific listed category cited. That document is also your first piece of evidence for a regulator asking why a system was or wasn't treated as high-risk.
The clock is already running
Prohibited AI practices took effect in February 2025. Obligations for general-purpose AI models — the foundation models many banks build on top of — took effect in August 2025. The core high-risk obligations under Title III, the ones that matter most for creditworthiness and insurance-pricing systems, apply from August 2026. If your Annex III systems don't already have a documented risk management system, you are behind the compliance clock, not ahead of it.
1. Build an AI inventory you can actually stand behind
You can't govern what you can't see, and the most common finding in a first-pass inventory exercise is shadow AI — a business unit running an AI tool nobody told compliance about. Catalogue every model, agent, and application with an owner, a stated purpose, documented data sources, and an explicit Annex III classification decision, not a placeholder.
2. Run Article 9's risk management system as a continuous process, not a sign-off
Article 9 requires a risk management system that runs across the entire lifecycle of a high-risk AI system — identification, estimation, evaluation, and mitigation of risks, re-assessed whenever the system changes materially. A one-time sign-off at launch does not satisfy this; the obligation is continuous, and your documentation needs to show iteration, not a single dated approval.
3. Govern your training and input data under Article 10
Article 10 requires documented data governance covering provenance, relevance, representativeness, and bias examination for training, validation, and testing datasets. Keep that evidence linked to the specific system it supports — a generic "our data governance policy" document will not satisfy an examiner asking about bias testing for one specific credit model.
4. Make human oversight under Article 14 real, not theoretical
Article 14 requires that high-risk systems be designed so a human can effectively oversee them — understand the system's capabilities and limitations, recognise signs of malfunction, and intervene or halt the system when needed. Define exactly where a human reviews or can override the output, and make sure the override path is actually logged and auditable. A review button that nobody has ever clicked is not evidence of oversight.
5. Put guardrails where Article 13's transparency obligations actually bite
Article 13 requires high-risk systems to be designed so their operation is sufficiently transparent for users to interpret output and use it appropriately. A runtime guardrail layer that intercepts unsafe or non-compliant outputs before they reach a customer is one of the more practical ways to satisfy this in a live deployment — it's considerably easier to meet transparency and safety obligations when a control enforces them automatically rather than relying on every output being individually reviewed.
6. Build the quality management system Article 17 actually requires
Article 17 obliges providers of high-risk systems to maintain a documented quality management system — covering regulatory compliance strategy, design control, data management, and post-market monitoring procedures. This is the document your examiner will ask to see first; most of what it needs can be assembled from controls you should already have, but it has to exist as a single traceable artifact, not scattered across departmental wikis.
7. Treat Article 72's post-market monitoring as an ongoing obligation, not an afterthought
Article 72 requires providers to actively monitor high-risk systems in production for drift, degradation, and emerging risks, and to act on what they find. Manual evidence collection does not scale to this requirement — build logging, alerting, and remediation workflows so the audit trail is a by-product of normal operation rather than a project you run before each review.
8. Map your controls once, then reuse them across frameworks
The EU AI Act overlaps substantially with NIST AI RMF, ISO/IEC 42001, SOC 2, and India-specific expectations under RBI's frameworks and the DPDP Act. Map each control once against a shared library and you satisfy multiple regimes from the same evidence base, instead of running parallel compliance programs that duplicate the same work five times over.
A five-point action checklist
- Produce a written Annex III applicability determination for every AI system, citing the specific listed category — not a general risk impression.
- Confirm your Article 9 risk management process re-triggers on material system changes, with dated evidence of each cycle.
- Verify Article 14 human-oversight override paths are logged and have actually been exercised at least once in testing.
- Build the Article 17 quality management system as a single document your examiner can review, not a scattered policy set.
- Map every EU AI Act control against NIST AI RMF, ISO 42001, and your RBI/DPDP obligations so one evidence base serves all four.