L'AI Act est une loi européenne. Application en cascade : février 2025 pour les interdictions, août 2026 pour les systèmes haut risque, août 2027 pour les modèles GPAI déjà sur le marché. Pour les banques, le haut risque vise les systèmes IA qui décident de l'accès au crédit, de la solvabilité d'une personne physique, ou du pricing assurance (annexe III, point 5). Le périmètre est concret, daté, nommé. Tous les DSI EU l'ont dans leur roadmap.

La lecture dominante est juridique : on parcourt la liste des cas haut risque, on dit "on n'y touchera pas", et on plafonne sur des cas péripheriques. C'est une lecture défensive — éviter par défaut, pas par design.

Le frein n'est pas dans la régulation seule. Il est dans son interaction avec une culture organisationnelle défensive — où chaque niveau se protège, où dire non par défaut est plus sûr que dire oui. La régulation ajoute une justification à un biais déjà installé. Le cycle de livraison s'allonge mécaniquement, alors que la régulation, lue comme un cahier des charges, est exécutable en quelques mois. Une archi pensée pour répondre aux articles 12 à 15 ne lève pas la culture défensive — mais elle donne au compliance officer les artefacts qui lui permettent de dire oui sans engager sa propre signature à l'aveugle.

La bonne lecture est architecturale. L'AI Act ne dit pas "n'utilisez pas l'IA sur le crédit". Il dit "si vous le faites, voici les exigences" : gouvernance des données (article 10), documentation technique (article 11), traçabilité (article 12), transparence (article 13), supervision humaine (article 14), robustesse et cybersécurité (article 15). Ce sont des exigences d'architecture, pas une liste de zones interdites. Une banque qui les conçoit dans son archi peut industrialiser sans peur de l'audit. Une banque qui ne les conçoit pas restera bloquée au pilote.

L'AI Act n'est pas une liste de zones interdites. C'est un cahier des charges d'architecture. Le frein réglementaire est un problème d'archi déguisé en problème juridique.

Cet article propose une lecture par l'archi : où, dans les workflows CIB et Asset Management, l'IA crée de la valeur, et quels patterns d'archi répondent par construction aux articles 12 à 15 de l'AI Act. Deux deep dives pour matérialiser, et cinq patterns transverses pour généraliser.

Cartographie des zones à valeur — matrice 2×2

Zone Use case Pattern d'archi Articles AI Act couverts
CIB Front Pre-Deal Intelligence M&A Decomposed Sub-Agents with Citation Proofs Art. 12, 13, 14, 50
CIB Back Trade Reporting Validation (EMIR, MiFID II, SFTR) LLM × Rules Engine Self-Correcting Loop Art. 9, 12, 14, 15
AM Front Portfolio Construction Assistant Adversarial Multi-Agent → Classical Optimizer Art. 13, 14, 15
AM Back NAV / Corporate Actions Engine AI Aggregator + Anomaly Gate + Human Sign-off Art. 12, 14, 15

Aucun de ces use cases n'est haut risque au sens de l'annexe III. Mais les concevoir au standard haut risque répond à trois objectifs : 1) anticiper un glissement réglementaire (ce qui n'est pas haut risque aujourd'hui peut l'être demain) ; 2) satisfaire la doctrine ACPR et la directive AMF de juillet 2025 qui calquent leur grille sur l'AI Act ; 3) répondre à DORA qui s'applique en parallèle pour la résilience opérationnelle des systèmes critiques.

CIB Front Office — Pre-Deal M&A. 2 à 4 semaines de travail analyst sur des sources hétérogènes : 10-K, earnings calls, brevets, base interne précédents deals. BNP Paribas a déployé en 2025 un Pitch Intelligence Portal alimenté par Mistral via sa plateforme LLM-as-a-Service. Deutsche Bank a mis en production DB Lumina (Gemini multimodal grounded) auprès de 5 000 utilisateurs IBD et FIC en septembre 2024. Crédit Agricole CIB génère des market reports personnalisés par profil client. Le baseline mondial : Hebbia et Rogo (Series C 160 M$ en 2026, partenariat OpenAI) — multi-agent orchestré avec citations sentence-level. C'est ce niveau d'archi que la zone EU doit cibler.

CIB Back Office — Trade Reporting. EMIR Refit, MiFID II, SFTR imposent une soumission T+1 aux trade repositories avec validation multi-niveaux. C'est aujourd'hui un white space EU — pas de déploiement banque Tier-1 communiqué. La fenêtre s'ouvre : la consultation CP25/16 de la FCA et de la BoE de juin 2025 ajoute un champ "Execution agent" applicable au 26 janvier 2026 — terrain mûr pour une archi conçue dès maintenant.

Asset Management Front Office — Portfolio Construction. Les optimiseurs classiques (Black-Litterman, mean-variance) restent au cœur de la construction de portefeuille. BlackRock a publié en août 2025 AlphaAgents : un système multi-agent LLM qui débat entre vues opposées, puis injecte les conclusions structurées dans un optimiseur classique. Un papier ICLR 2025 démontre l'archi LLM-Views → Black-Litterman (sentiment multi-LLM agrégé via LSTM, Sharpe 3.02 backtest S&P 500). Le pattern transposable EU : l'IA génère des views, l'optimizer reste classique et auditable.

Asset Management Back Office — NAV / Corporate Actions. Le calcul quotidien de la VL implique la classification de centaines de flux : dividendes, coupons, corporate actions. Une CA non détectée à temps = une VL fausse = un risque de litige LP. Les fund admins Tier-1 (BNY, Grant Thornton, Caceis) communiquent sur des NAV en moins de 5 minutes avec anomaly detection systématique. BlackRock Aladdin Copilot fonctionne sous le même régime — content filtering, garde-fous, pas d'investment advice.

Front et back ne sont pas séparables. Un assistant pre-deal génère des données qui doivent être archivées, auditées, et liées au deal une fois clos. Une réconciliation back rapide débloque de la liquidité disponible front.

Exemple terrain : une exécution sur option dont l'économie n'avait pas de sens, traitée comme une exécution normale en back office. Le back l'enregistre, valorise, réconcilie. Aucune remontée vers le front. Le pattern n'est pas un manque d'outils — c'est une convention organisationnelle : le back encaisse les effets, le front maîtrise les causes, personne ne croise les deux.

Les deux deep dives qui suivent — un CIB Front, un AM Back — matérialisent ce que ces patterns donnent concrètement.

Deep dive 1 — Pre-Deal Intelligence M&A (CIB Front Office)

Le besoin métier

Un mandat M&A advisory commence par 2 à 4 semaines de préparation : profil cible, comparables boursiers, precedent transactions, thèses d'acquisition, risques. C'est un travail d'analyst — 60 à 80% du temps junior — sur des sources hétérogènes :

  • documents publics (10-K, 20-F, prospectus, communiqués)
  • transcripts d'earnings calls
  • bases de données financières (Bloomberg, Refinitiv, Capital IQ)
  • brevets et propriété intellectuelle
  • base interne des précédents deals de la banque

L'IA générative ne remplace pas l'analyst. Elle déplace son point d'intervention : de la collecte vers la décision.

Pattern d'archi — Decomposed Sub-Agents with Citation Proofs

Le réflexe est de faire un "RAG monolithique" : une seule passe de retrieval, un seul prompt LLM, sortie texte libre. Cette archi ne passe pas en CIB advisory — pas pour des raisons techniques, pour des raisons fiduciaires. Impossible à auditer, citations approximatives, pas de séparation des préoccupations.

L'archi qui passe décompose le travail en sous-agents spécialisés, chacun avec sa source, sa logique, et son audit trail propre. La génération finale ne se permet aucune affirmation sans citation sentence-level — pattern industrialisé par Hebbia sous le nom "sentence-level proof".

flowchart TB
  subgraph LANE_SRC["Lane — Sources externes"]
    direction LR
    S1[10-K / 20-F]
    S2[Earnings calls]
    S3[News & PR]
    S4[Brevets USPTO/EPO]
    S5[Base précédents deals]
  end

  subgraph LANE_AI["Lane — Sous-agents IA"]
    direction LR
    A1[Agent Profil cible<br/>& comparables]
    A2[Agent Précédents<br/>transactions]
    A3[Agent Tech<br/>brevets & PI]
    A4[Agent Risques<br/>litiges & news]
  end

  subgraph LANE_CITE["Lane — Citation Layer"]
    direction LR
    C1[Sentence-level<br/>grounding]
    C2[Confidence<br/>scoring]
    C3[Source<br/>provenance]
  end

  subgraph LANE_SYNTH["Lane — Synthèse structurée"]
    direction LR
    O1[Profil cible]
    O2[Multiples comparables]
    O3[Thèses d'acquisition]
    O4[Risques identifiés]
  end

  subgraph LANE_HUMAN["Lane — Analyst senior (humain)"]
    direction LR
    G1[Audit trail review]
    G2[Validation]
    G3[Lock-in livrable client]
  end

  LANE_SRC --> LANE_AI
  LANE_AI --> LANE_CITE
  LANE_CITE --> LANE_SYNTH
  LANE_SYNTH --> LANE_HUMAN
  LANE_HUMAN -. feedback .-> LANE_AI

Cinq couches.

1. Sources. Multi-format, multi-fournisseur, multi-confidentialité. Le défi n'est pas l'ingestion (les ETL existent) — c'est la classification par sensibilité. Un 10-K public et une data room sous NDA n'ont pas le même régime de traitement ni les mêmes droits d'accès downstream.

2. Sous-agents spécialisés. Un agent par sous-tâche, avec son retrieval, son prompt, son schéma de sortie. Pas de super-prompt qui essaie de tout faire. Ce découpage est l'écart entre une archi auditable (chaque sous-agent a son log) et une archi opaque (un seul appel LLM avec 50K tokens de contexte). C'est aussi ce qui rend le système ré-utilisable : ajouter une source ne casse pas le reste.

3. Citation Layer. Aucune affirmation sans citation sentence-level. C'est l'archi qui le garantit, pas une instruction prompt qu'on espère respectée. Chaque fait produit par un sous-agent porte son ID source + son offset dans le document + son score de confiance.

4. Synthèse structurée. Sortie au format pitch book, pas texte libre. Profil cible normalisé, tableau de comparables, thèses formatées. La sortie alimente directement les templates internes — sans copier-coller manuel qui casse la traçabilité.

5. Gouvernance. Audit trail séparé par sous-agent, validation analyst senior obligatoire avant inclusion dans un livrable client, lock-in une fois le livrable envoyé. Sans cette couche, le pipeline est inutilisable en CIB advisory.

Mapping AI Act

Couche Article AI Act Comment l'archi répond
Sous-agents (logs par tâche) Art. 12 — Traçabilité Chaque sous-agent journalise ses entrées, sa requête, sa sortie. Reconstruction de la décision possible a posteriori.
Citation Layer Art. 13 — Transparence L'analyst voit la phrase exacte à l'origine de chaque affirmation. La provenance est explicite, pas inférée.
Validation analyst senior Art. 14 — Supervision humaine Pas d'envoi client sans validation humaine matérialisée. Le contrôle est dans le workflow, pas dans une charte.
Usage de modèles fondation Art. 50 — Transparence GPAI Le fournisseur de LLM (Mistral, OpenAI, Anthropic) est documenté ; les conditions d'usage sont contractualisées.

L'agent ne génère pas un pitch book. Il prépare un substrat structuré que l'analyst transforme. La décision finale reste humaine, l'audit trail est natif, chaque affirmation est traçable jusqu'à sa phrase source — trois propriétés que l'AI Act exige pour les systèmes haut risque et que cette archi délivre par construction.

Deep dive 2 — NAV / Corporate Actions Engine (AM Back Office)

Le besoin métier

Une société de gestion calcule chaque jour la valeur liquidative (VL) de ses fonds. C'est l'obligation centrale de l'administration de fonds. Le calcul implique de classifier des centaines de flux quotidiens : dividendes, coupons, corporate actions (splits, fusions, OPA, distributions exceptionnelles, échanges de titres).

Une corporate action non détectée à temps = une VL fausse = un risque de litige LP, voire un incident d'exploitation déclaré au régulateur. Le travail est aujourd'hui fait par des fund accountants. Il est répétitif, à forte exigence d'exactitude, et structurellement automatisable — avec une marge d'erreur minime.

Cas piégeux courant : le dividende optionnel. Le porteur choisit cash ou réinvestissement en titres (DRIP). La fenêtre d'instruction au custodian est courte — 5 à 10 jours ouvrés selon l'émetteur. Si la société de gestion instruit en titres mais que l'allocation effective arrive après le cut-off de calcul VL, la VL publiée ne reflète pas la position réelle. Incident opérationnel déclarable à l'AMF, et un break sur la réconciliation du lendemain.

Pattern d'archi — AI Aggregator + Anomaly Gate + Human Sign-off

Contre-intuition utile : la solution n'est pas un agent autonome LLM-centric. C'est une archi où l'IA agrège et classe, des règles déterministes valident, et un humain signe. Le LLM ne calcule pas la VL — il accélère la classification et la détection d'anomalies.

flowchart TB
  subgraph LANE_SRC["Lane — Sources externes"]
    direction LR
    F1[Positions par fonds]
    F2[Prix marché<br/>multi-sources]
    F3[Flux cash<br/>div, coupons]
    F4[CA feed<br/>Reuters / BBG / custodian]
  end

  subgraph LANE_AI["Lane — AI Aggregator"]
    direction LR
    A1[Classification LLM<br/>event type + confidence]
    A2[Mapping<br/>fonds impactés]
    A3[Calcul ajustement]
  end

  subgraph LANE_RECON["Lane — Réconciliation"]
    direction LR
    R1[Position interne<br/>vs custodian]
    R2[Détection écarts]
    R3[Explication LLM<br/>du break]
  end

  subgraph LANE_RULES["Lane — Rules Engine (déterministe)"]
    direction LR
    V1[Tolérances métier]
    V2[Détection prix<br/>saut 3σ]
    V3[Routing auto vs humain]
  end

  subgraph LANE_HUMAN["Lane — Fund accountant (humain)"]
    direction LR
    H1[Traitement<br/>exceptions]
    H2[Sign-off VL]
    H3[Audit trail<br/>10 ans]
  end

  LANE_SRC --> LANE_AI
  LANE_AI --> LANE_RECON
  LANE_RECON --> LANE_RULES
  LANE_RULES -->|haute confiance + dans tolérance| H3
  LANE_RULES -->|exception| H1
  H1 --> H2 --> H3

Cinq modules.

1. Flux d'entrée. Positions par fonds depuis le système comptable, prix marché multi-sources avec règle de fallback, flux cash (dividendes, coupons) et feed corporate actions (Reuters, Bloomberg, Euronext, custodians).

2. AI Aggregator. Un LLM classifie les events entrants par type (mandatory cash dividend, optional stock dividend, merger, spin-off, rights issue), identifie les fonds impactés via le référentiel positions, et calcule l'ajustement à appliquer. Chaque classification produit un niveau de confiance — c'est cette confidence qui pilote le routing downstream, pas une logique tout-ou-rien.

3. Réconciliation. Comparaison des positions internes vs custodian (Caceis, BNP Securities Services, State Street, BBH). Les breaks sont classifiés par nature : timing, quantité, prix, mauvaise allocation. Un LLM produit une explication structurée du break — accélération documentée de 40 à 60% sur la résolution, avec NAV final < 5 minutes annoncé par les fund admins Tier-1.

4. Anomaly Gate. Couche déterministe non-négociable. Un rules engine applique les tolérances métier (saut de prix > 3σ vs historique, écart de réconciliation > seuil par classe d'actifs, classification CA avec confidence < 0.85). Le gate route automatiquement : haute confiance + dans tolérance → publication ; sinon → fund accountant.

5. Human Sign-off. Pour tout ce qui ne passe pas le gate, un fund accountant tranche. La VL n'est publiée qu'après signature, avec audit trail complet : qui a validé quoi, à quel moment, sur la base de quelles sources. Conservation 10 ans minimum.

Mapping AI Act + DORA

Couche Article Comment l'archi répond
AI Aggregator (logs de classification + confidence) Art. 12 AI Act — Traçabilité Chaque event classifié est journalisé avec son score et son routing. Re-jeu possible.
Anomaly Gate (rules engine déterministe) Art. 15 AI Act — Robustesse Le gate garantit une borne déterministe ; le système ne dépend pas de la fiabilité du seul LLM.
Human Sign-off (fund accountant signe les exceptions) Art. 14 AI Act — Supervision humaine Aucune VL publiée sans signature humaine sur les cas non-conformes.
Audit trail conservé 10 ans DORA — Résilience et reporting d'incidents Tout incident potentiel (VL erronée) est reconstructible ; obligation de notification au régulateur tenue.

Contrairement au front office, la marge d'erreur est minime. L'autonomie de l'agent est limitée par construction : il agrège et propose, le rules engine déterministe gate, le fund accountant signe. L'IA accélère, elle ne décide pas.

Cinq patterns d'archi qui passent l'AI Act

Au-delà des cas spécifiques, cinq patterns reviennent dans les déploiements qui passent les audits.

1. Insertion sans autonomie pleine — AI Gate humain ou rules engine

→ Article 14 — Supervision humaine

L'IA propose. Une logique déterministe (rules engine) ou un humain (fund accountant, analyst senior) valide. Le seuil d'autonomie dépend du risque réglementaire de la zone d'insertion :

Zone Niveau d'autonomie acceptable
Research, drafting, search (CIB pre-deal) Élevée — pas de décision réglementée
Decision support (pré-trade analytics, attribution) Modérée — humain dans la boucle
Decision making (credit scoring, suitability, VL) Faible — gate déterministe + humain

Le gate n'est pas une post-rationalisation. C'est un composant d'archi explicite — un service ou un middleware, pas un commentaire dans le code.

2. Citation Proofs at Generation Time

→ Articles 12 (Traçabilité) et 13 (Transparence)

L'AI Act exige une explicabilité des systèmes haut risque. Cette explicabilité ne s'ajoute pas après — elle se conçoit dans l'archi. Chaque affirmation produite par un agent porte son ID source + offset + score de confiance. Hebbia a industrialisé ce pattern sous le nom "sentence-level proof".

L'ACPR a formalisé un framework à quatre niveaux d'explicabilité : observation, justification, approximation, réplication. Une archi à citations sentence-level couvre directement les niveaux 2 et 3 par construction.

3. LLM × Rules Engine — Self-Correcting Loop

→ Articles 9 (Gestion des risques) et 15 (Robustesse)

Pour les zones où la sortie doit respecter des règles dures (reporting réglementaire, classification produit MiFID II, codification corporate actions), le pattern qui passe consiste à coupler le LLM à un rules engine déterministe :

  1. Le LLM extrait ou propose (souple, gère bruit et ambiguïté)
  2. Le rules engine valide (déterministe, auditable, documenté)
  3. Si rejet, le rules engine retourne l'erreur structurée au LLM
  4. Le LLM corrige ; itération limitée (3 tours max), sinon escalade humaine
  5. Audit trail de chaque tour

Ce pattern résout le dilemme "LLM créatif mais hallucine" vs "rules engine fiable mais rigide". On garde les deux propriétés en séparant les rôles. L'archi naturelle du trade reporting validation et de tout workflow où la sortie doit satisfaire un schéma strict.

4. Periphéral first

→ Article 9 — Système de gestion des risques

Les banques US déploient parfois directement dans des zones régulées. Les banques EU qui réussissent commencent par les zones péripheriques :

  • documents internes (research, audit, compliance reporting)
  • communication non-client (rapports management, slides comité)
  • back office non-décisionnel (réconciliation, classification, anomaly detection)

Ces zones génèrent de la valeur, accumulent du capital opérationnel sur l'IA, et préparent les déploiements ultérieurs sur les zones régulées avec une gouvernance déjà rodée. Ce n'est pas un pattern timide — c'est stratégique. Une banque qui essaie de déployer directement sur la décision crédit ou la suitability MiFID II sans capital opérationnel IA va se prendre l'audit en pleine figure.

5. Data residency comme contrainte d'archi

→ Hors AI Act — DORA, RGPD, Schrems II

L'AI Act ne traite pas explicitement de la résidence des données. DORA, RGPD et Schrems II le font. Convergence claire : les données financières sensibles ne peuvent pas sortir du périmètre maîtrisable. Cela ne signifie pas "pas d'IA US". Cela signifie "déploiement on-premise, VPC, ou fournisseur EU".

C'est dans ce contexte que Mistral AI joue un rôle particulier. Société française, soumise au droit EU, proposant un déploiement on-premise ou en cloud privé, partenaire de BNP Paribas (~100 cas d'usage en production, partenariat renouvelé pour 3 ans en février 2026) et déployée chez HSBC dans le périmètre data center interne. Ce n'est pas un alignement idéologique — c'est une réponse industrielle à une contrainte d'archi.

L'AI Act comme cahier des charges

Le débat sur l'IA en finance EU se trompe de question. La bonne question n'est pas "comment éviter l'AI Act ?". C'est : "comment concevoir une archi qui répond aux articles 12 à 15 par construction ?".

Pour les institutions qui veulent industrialiser :

  1. Cartographier les zones (front/back × métier) — pas viser un cas isolé
  2. Identifier les zones péripheriques qui génèrent de la valeur sans tomber en annexe III
  3. Concevoir la gouvernance dans l'archi : citation proofs, audit trail par composant, gates déterministes, supervision humaine matérialisée — pas en post-traitement
  4. Coupler systématiquement LLM et logique déterministe pour les zones à sortie contrainte
  5. Choisir le fournisseur en fonction de la data residency (DORA), pas du benchmark MMLU

Une banque qui conçoit à ce standard sur ses use cases péripheriques pourra glisser vers des zones haut risque sans refonte d'archi. Une banque qui ne le conçoit pas restera coincée en pilote — sur les périphériques aussi, parce que l'ACPR n'attendra pas.

Pour aller plus loin

  • EU AI Act — texte officiel, articles 9 à 15 pour les exigences haut risque
  • ACPR / Banque de France — framework de gouvernance des algorithmes IA en finance, quatre niveaux d'explicabilité
  • AMF — directive juillet 2025 sur l'utilisation de l'IA par les institutions financières
  • DORA — règlement résilience opérationnelle, applicable depuis janvier 2025
  • ESMA — guidelines sur les systèmes algorithmiques et l'IA dans les services financiers
  • BlackRock Research — AlphaAgents (août 2025), multi-agent LLM pour construction de portefeuille
  • Hebbia — sentence-level proof RAG, référence pour les pipelines auditables
  • ICLR 2025 — LLM-Views to Black-Litterman, papier sur l'agrégation multi-LLM en allocation
  • Mistral AI — mistral.ai/industry/finance