Most AI deployments in regulated industries fail at compliance, not at capability. The technology works. The governance does not. The failure pattern is consistent: a team builds a working AI system, then discovers that the audit trail is insufficient, the human oversight gate is missing, or the data processing basis under GDPR is undocumented. Remediation costs 3 to 5 times more than building correctly from the start. This checklist maps the architecture decisions that determine compliance before a single line of production code is written, structured around the four regulatory frameworks that apply to AI deployment in European financial services in 2026.
Applicable to all AI systems processing personal data of EU residents. Must be completed before data ingestion begins.
For each input data type used by the AI system, document whether the basis is legitimate interest, contractual necessity, consent, or legal obligation. Legitimate interest requires a documented balancing test. This cannot be added retroactively after a regulator request.
Only process personal data that is strictly necessary for the AI task. Document which fields are used and why. Remove or pseudonymise fields not required for inference. A common failure: ingesting full CRM records when only 4 fields are needed.
Required when AI processing is likely to result in high risk to individuals, including automated decision-making, large-scale processing of sensitive data, or systematic monitoring. For financial AI systems, a DPIA is almost always required. Document findings and mitigations before deployment.
Where AI output significantly affects individuals (credit decisions, insurance pricing, KYC approval), implement: the right to human review, the right to contest the decision, and the right to an explanation. These rights must be operationally functional, not merely stated in a privacy policy.
Specify how long input data, model outputs, and audit logs are retained. Financial records typically require 5 to 7 years. Personal data used only for AI inference should be deleted once the purpose is fulfilled. Automated deletion schedules must be implemented and tested.
If using a US-based LLM API (OpenAI, Anthropic, Google), confirm the transfer mechanism: Standard Contractual Clauses (SCCs), adequacy decision, or other. Confirm that personal data sent to the API is covered by the DPA. Do not assume API providers are compliant by default.
Applicable to AI systems deployed from August 2026. High-risk classification triggers mandatory conformity requirements. Assessment must precede procurement or build decisions.
Financial services AI systems used in credit scoring, insurance underwriting, and employment decisions are classified as High Risk. AI used for internal automation (report drafting, data aggregation) without direct individual impact is typically Limited or Minimal Risk. Document the classification rationale.
High-risk AI systems require: general description of the system, design specifications, training methodology, performance metrics, known limitations, and human oversight measures. This documentation must be maintained and updated throughout the system lifecycle.
High-risk AI systems used in financial services must be registered in the EU AI Act database maintained by the European AI Office before being placed on the market or put into service. This requirement applies from August 2026.
Human oversight must be operational, not nominal. Each high-risk AI output must route to a named role with authority to review and override. The override action must be logged. A checkbox in a UI that nobody reads does not constitute oversight.
For decisions affecting individuals, explanations must describe the main factors influencing the output in terms the affected person can understand. "The model scored you 0.34" is not an explanation. "Your application was declined because the declared revenue did not match the filed accounts" is.
Applicable to all production AI systems in regulated environments. Audit trail requirements apply independently of EU AI Act risk classification.
Every AI inference must log: the input data hash (not the raw data if sensitive), the model version and configuration, the timestamp, the output, the human reviewer identity, and any override action. Logs must be immutable and stored separately from the operational system.
Financial services AI logs must be retained for at least 5 years (7 years for MiFID II firms). Logs must be retrievable within 72 hours for regulatory inspection. Test retrieval annually.
Run a simulated regulatory inspection: given a past AI output, can you reconstruct exactly what data was used, which model version was active, and what human action followed? If not, the audit trail is incomplete. This test must be documented.
Document what constitutes an AI incident (model drift, anomalous outputs, data breach via AI pipeline), who is notified, what the rollback procedure is, and the reporting timeline to regulators. DORA requires financial entities to report major ICT incidents within 4 hours of detection.
Production AI systems must be monitored for performance degradation, distributional shift in inputs, and anomalous output patterns. Set automated alerts for threshold breaches. Define the human review trigger: what output pattern requires immediate suspension pending investigation.
Requirements specific to regulated financial entities. Complement, not replace, the general requirements in Parts 1 to 3.
AI models used in credit assessment must comply with EBA model risk management guidelines, including independent validation, documentation of model assumptions, backtesting against historical outcomes, and defined approval workflows for model changes.
AI systems used in credit, insurance, and employment decisions must be tested for discriminatory outcomes across protected characteristics (gender, age, ethnicity, disability). Document testing methodology and results. Disparate impact findings must be remediated before production deployment.
AI-generated ESG scores or assessments used in SFDR Article 8 or 9 product disclosures must have documented data sources, aggregation methodologies, and known limitations. Regulators and auditors will request this documentation during product review cycles.
If an AI provider is classified as critical ICT third-party under DORA, specific contractual provisions are required: audit rights, subcontractor disclosure, business continuity requirements, and exit provisions. Financial entities must maintain a register of all ICT third-party arrangements.
The single most common compliance failure: building the AI system first and treating compliance as a documentation exercise at the end. Every item in this checklist represents an architecture decision. Once the system is built, changing the audit trail, the human oversight gate, or the data processing basis requires rebuilding, not documenting. Compliance-first means these decisions are made in week one, not week twelve.
What does compliance-first AI mean in practice?
Compliance-first AI means designing audit trails, human oversight gates, data minimisation, and explainability into the system architecture before writing a single line of production code. It is the opposite of the common approach of building fast and retrofitting compliance later, which consistently fails in regulated environments.
Which EU regulations apply to AI deployment in financial services?
The primary frameworks are the EU AI Act (risk-based classification, most provisions applicable from August 2026), GDPR (data protection by design, automated decision-making restrictions under Article 22), DORA (digital operational resilience for financial entities), and sector-specific guidelines from the EBA, ESMA, and national regulators such as the ACPR in France.
What is the EU AI Act risk classification for AI in financial services?
AI systems used in credit scoring, insurance underwriting, and employment decisions in financial services are classified as High Risk under Annex III of the EU AI Act. High-risk systems require conformity assessment, technical documentation, human oversight mechanisms, and registration in the EU database before deployment.
Can AI agents make autonomous decisions in regulated financial workflows?
AI agents can automate preparation, aggregation, and flagging steps, but final decisions with legal or contractual consequences must include a documented human approval gate. GDPR Article 22 restricts solely automated decisions that significantly affect individuals. The EU AI Act requires human oversight for high-risk AI systems.
How do you build an audit trail for an AI system in financial services?
An AI audit trail must log: input data used (with timestamps and source identifiers), the model version active at inference time, the output produced, any human review or override actions, and the final decision and actor. Logs must be immutable, retained for the regulatory minimum (typically 5 to 7 years), and accessible to internal audit and regulators on request.
Related resources on this site
Deploying AI in a regulated environment without a compliance architecture review is the most expensive shortcut in financial services. Let's build it right from the start.
Book a compliance architecture reviewLast updated: March 2026. EU AI Act provisions and EBA guidelines evolve. This checklist reflects the regulatory framework as of Q1 2026. Consult qualified legal counsel for jurisdiction-specific advice.
La plupart des déploiements IA dans les industries régulées échouent sur la conformité, pas sur la capacité. La technologie fonctionne. La gouvernance, non. Le pattern d'échec est constant : une équipe construit un système IA fonctionnel, puis découvre que la piste d'audit est insuffisante, que la gate de supervision humaine est absente, ou que la base juridique du traitement des données sous le RGPD n'est pas documentée. La remédiation coûte 3 à 5 fois plus cher que de construire correctement dès le départ. Cette checklist cartographie les décisions d'architecture qui déterminent la conformité avant qu'une seule ligne de code de production soit écrite, structurée autour des quatre cadres réglementaires applicables au déploiement IA dans les services financiers européens en 2026.
Applicable à tous les systèmes IA traitant des données personnelles de résidents UE. À compléter avant le début de l'ingestion de données.
Pour chaque type de données d'entrée utilisé par le système IA, documenter si la base est l'intérêt légitime, la nécessité contractuelle, le consentement, ou l'obligation légale. L'intérêt légitime exige un test de mise en balance documenté. Cela ne peut pas être ajouté rétroactivement suite à une demande réglementaire.
Ne traiter que les données personnelles strictement nécessaires à la tâche IA. Documenter quels champs sont utilisés et pourquoi. Supprimer ou pseudonymiser les champs non nécessaires à l'inférence. Échec courant : ingérer des enregistrements CRM complets quand seulement 4 champs sont nécessaires.
Obligatoire lorsque le traitement IA est susceptible d'engendrer un risque élevé pour les personnes, notamment la prise de décision automatisée, le traitement à grande échelle de données sensibles, ou la surveillance systématique. Pour les systèmes IA financiers, une AIPD est presque toujours requise.
Lorsque l'output IA affecte significativement des personnes (décisions de crédit, tarification assurance, approbation KYC), mettre en oeuvre : le droit à une révision humaine, le droit de contester la décision, et le droit à une explication. Ces droits doivent être opérationnellement fonctionnels, pas simplement mentionnés dans une politique de confidentialité.
Spécifier la durée de conservation des données d'entrée, des outputs du modèle, et des journaux d'audit. Les archives financières exigent généralement 5 à 7 ans. Les données personnelles utilisées uniquement pour l'inférence IA doivent être supprimées une fois l'objectif atteint. Des calendriers de suppression automatisés doivent être implémentés et testés.
Si vous utilisez une API LLM américaine (OpenAI, Anthropic, Google), confirmez le mécanisme de transfert : Clauses Contractuelles Types (CCT), décision d'adéquation, ou autre. Confirmez que les données personnelles envoyées à l'API sont couvertes par l'accord de traitement des données. Ne pas supposer que les fournisseurs API sont conformes par défaut.
Applicable aux systèmes IA déployés à partir d'août 2026. La classification haut risque déclenche des exigences de conformité obligatoires. L'évaluation doit précéder les décisions d'achat ou de construction.
Les systèmes IA des services financiers utilisés pour le scoring de crédit, la souscription d'assurance, et les décisions d'emploi sont classés Haut Risque. L'IA utilisée pour l'automatisation interne (rédaction de rapports, agrégation de données) sans impact direct sur les individus est généralement à Risque Limité ou Minimal. Documenter la justification de la classification.
Les systèmes IA haut risque exigent : description générale du système, spécifications de conception, méthodologie d'entraînement, métriques de performance, limitations connues, et mesures de supervision humaine. Cette documentation doit être maintenue et mise à jour tout au long du cycle de vie du système.
Les systèmes IA haut risque utilisés dans les services financiers doivent être enregistrés dans la base de données de l'AI Act tenue par le Bureau européen de l'IA avant d'être mis sur le marché ou mis en service. Cette exigence s'applique à partir d'août 2026.
La supervision humaine doit être opérationnelle, pas nominale. Chaque output IA haut risque doit être routé vers un rôle nommé avec autorité de révision et d'annulation. L'action d'annulation doit être journalisée. Une case à cocher dans une interface que personne ne lit ne constitue pas une supervision.
Pour les décisions affectant des individus, les explications doivent décrire les principaux facteurs influençant l'output dans des termes compréhensibles par la personne concernée. "Le modèle vous a attribué un score de 0,34" n'est pas une explication. "Votre dossier a été refusé car les revenus déclarés ne correspondent pas aux comptes déposés" en est une.
Applicable à tous les systèmes IA en production dans les environnements régulés. Les exigences de piste d'audit s'appliquent indépendamment de la classification de risque de l'AI Act.
Chaque inférence IA doit journaliser : le hash des données d'entrée (pas les données brutes si sensibles), la version et configuration du modèle, l'horodatage, l'output, l'identité du réviseur humain, et toute action d'annulation. Les journaux doivent être immuables et stockés séparément du système opérationnel.
Les journaux IA des services financiers doivent être conservés au moins 5 ans (7 ans pour les entreprises MiFID II). Les journaux doivent être récupérables en 72 heures pour une inspection réglementaire. Tester la récupération annuellement.
Réaliser une inspection réglementaire simulée : à partir d'un output IA passé, pouvez-vous reconstruire exactement quelles données ont été utilisées, quelle version du modèle était active, et quelle action humaine a suivi ? Si non, la piste d'audit est incomplète. Ce test doit être documenté.
Documenter ce qui constitue un incident IA (dérive du modèle, outputs anormaux, violation de données via le pipeline IA), qui est notifié, quelle est la procédure de rollback, et le délai de signalement aux régulateurs. DORA exige que les entités financières signalent les incidents ICT majeurs dans les 4 heures suivant la détection.
Les systèmes IA en production doivent être surveillés pour détecter la dégradation des performances, le décalage de distribution dans les inputs, et les patterns d'output anormaux. Configurer des alertes automatisées pour les dépassements de seuils. Définir le déclencheur de révision humaine : quel pattern d'output nécessite une suspension immédiate en attente d'investigation.
Exigences spécifiques aux entités financières régulées. Complètent, sans remplacer, les exigences générales des Parties 1 à 3.
Les modèles IA utilisés dans l'évaluation du crédit doivent respecter les lignes directrices EBA sur la gestion du risque de modèle, incluant la validation indépendante, la documentation des hypothèses du modèle, le backtesting sur les résultats historiques, et des workflows d'approbation définis pour les changements de modèle.
Les systèmes IA utilisés dans les décisions de crédit, d'assurance et d'emploi doivent être testés pour les résultats discriminatoires selon les caractéristiques protégées (genre, âge, origine ethnique, handicap). Documenter la méthodologie et les résultats des tests. Les conclusions d'impact disproportionné doivent être remédiées avant le déploiement en production.
Les scores ou évaluations ESG générés par IA utilisés dans les divulgations de produits SFDR Article 8 ou 9 doivent avoir des sources de données documentées, des méthodologies d'agrégation, et des limitations connues. Les régulateurs et auditeurs demanderont cette documentation lors des cycles de revue de produits.
Si un fournisseur IA est classifié comme tiers ICT critique sous DORA, des dispositions contractuelles spécifiques sont requises : droits d'audit, divulgation des sous-traitants, exigences de continuité d'activité, et dispositions de sortie. Les entités financières doivent tenir un registre de tous les arrangements de tiers ICT.
L'échec de conformité le plus courant : construire le système IA en premier et traiter la conformité comme un exercice de documentation à la fin. Chaque point de cette checklist représente une décision d'architecture. Une fois le système construit, modifier la piste d'audit, la gate de supervision humaine, ou la base juridique du traitement nécessite une reconstruction, pas une documentation. Compliance-first signifie que ces décisions sont prises en semaine un, pas en semaine douze.
Que signifie concrètement une IA compliance-first ?
Une IA compliance-first signifie concevoir les pistes d'audit, les gates de supervision humaine, la minimisation des données et l'explicabilité dans l'architecture du système avant d'écrire une seule ligne de code de production. C'est l'opposé de l'approche courante consistant à construire rapidement et à remédier la conformité après coup, qui échoue systématiquement en environnement régulé.
Quelles réglementations UE s'appliquent au déploiement IA dans les services financiers ?
Les cadres principaux sont l'AI Act européen (classification par risque, la plupart des dispositions applicables à partir d'août 2026), le RGPD (protection des données par conception, restrictions sur la prise de décision automatisée sous l'Article 22), DORA (résilience opérationnelle numérique pour les entités financières), et les lignes directrices sectorielles de l'EBA, de l'ESMA, et des régulateurs nationaux comme l'ACPR en France.
Quelle est la classification de risque AI Act pour l'IA dans les services financiers ?
Les systèmes IA utilisés pour le scoring de crédit, la souscription d'assurance, et les décisions d'emploi dans les services financiers sont classifiés Haut Risque sous l'Annexe III de l'AI Act. Les systèmes haut risque exigent une évaluation de conformité, une documentation technique, des mécanismes de supervision humaine, et un enregistrement dans la base de données UE avant déploiement.
Les agents IA peuvent-ils prendre des décisions autonomes dans des workflows financiers régulés ?
Les agents IA peuvent automatiser les étapes de préparation, d'agrégation et de signalement, mais les décisions finales aux conséquences légales ou contractuelles doivent inclure une gate d'approbation humaine documentée. L'Article 22 du RGPD restreint les décisions entièrement automatisées affectant significativement les individus. L'AI Act exige une supervision humaine pour les systèmes IA haut risque.
Comment construire une piste d'audit pour un système IA dans les services financiers ?
Une piste d'audit IA doit journaliser : les données d'entrée utilisées (avec horodatages et identifiants de source), la version du modèle active au moment de l'inférence, l'output produit, toute action de révision ou d'annulation humaine, et la décision finale et son auteur. Les journaux doivent être immuables, conservés pendant le minimum réglementaire (généralement 5 à 7 ans), et accessibles à l'audit interne et aux régulateurs sur demande.
Ressources associées sur ce site
Déployer l'IA dans un environnement régulé sans revue d'architecture conformité est le raccourci le plus coûteux des services financiers. Construisons correctement dès le départ.
Réserver une revue d'architecture conformitéDernière mise à jour : mars 2026. Les dispositions de l'AI Act et les lignes directrices EBA évoluent. Cette checklist reflète le cadre réglementaire du T1 2026. Consultez un conseil juridique qualifié pour des conseils spécifiques à votre juridiction.