Une chaîne d'approvisionnement de fournisseur d'IA de niveau bancaire est une chaîne dans laquelle chaque artefact qui atteint la production peut être retracé jusqu'à la source examinée, reconstruit selon le même résumé et vérifié cryptographiquement avant son exécution. Concrètement, le fournisseur peut démontrer des créations d'images propriétaires reproductibles, des signatures vérifiées par un contrôleur d'admission au moment du déploiement, une provenance lisible par machine et une nomenclature logicielle pour chaque version, ainsi qu'un chemin de publication où les humains ne peuvent pas pousser un artefact non vérifié autour des contrôles. En vertu de la loi sur la résilience opérationnelle numérique (DORA), règlement (UE) 2022/2554, la banque a le devoir d'évaluer exactement cela avant de signer, de sorte qu'un fournisseur sérieux arrive avec les preuves préparées. Cet article décrit chaque pratique, les preuves qu'un évaluateur devrait demander à voir, la disposition DORA que chacune sert et une liste de contrôle de questions qu'une équipe de gestion des risques technologiques ou d'approvisionnement peut présenter à n'importe quel fournisseur d'IA.
Les pratiques décrites ici sont celles que KLA applique pour sa propre version ; les pages Sécurité et Trust Center contiennent les revendications permanentes. Pour une vision plus large du contrôle des agents dans le secteur bancaire, commencez par le Guide de gouvernance de l'IA dans le secteur bancaire.
Pourquoi la chaîne d'approvisionnement en logiciels est une question DORA
DORA a été adoptée le 14 December 2022 et s'applique aux entités financières de l'UE depuis 17 January 2025. Son chapitre V, « Gestion du risque tiers lié aux TIC », régit la manière dont une entité financière contracte pour une technologie externe. Les définitions font le travail initial. L'article 3(19) définit un fournisseur de services TIC tiers comme "une entreprise fournissant des services TIC", une définition suffisamment large pour couvrir pratiquement tous les fournisseurs d'IA. L'article 3(22) définit une fonction critique ou importante comme celle dont la perturbation, ou dont l'exécution interrompue, défectueuse ou défaillante, nuirait sensiblement à la performance financière de l'entité, à la solidité ou à la continuité de ses services, ou à son respect continu des conditions de son autorisation. Un système d’IA qui filtre les transactions, trie les alertes AML ou contrôle le déblocage des paiements prendra souvent en charge une telle fonction une fois que la banque aura effectué l’auto-évaluation documentée.
Cette classification place la barre plus haut pour l'ensemble de l'engagement. L'article 28(4) exige que l'entité financière, avant de conclure le contrat, identifie et évalue tous les risques pertinents et fasse preuve de diligence raisonnable à l'égard du fournisseur potentiel. L'article 28(5) autorise la conclusion de contrats uniquement avec des fournisseurs qui se conforment aux normes de sécurité des informations appropriées et exige, pour les fonctions critiques ou importantes, une prise en compte appropriée de l'utilisation par le fournisseur des normes de sécurité des informations les plus récentes et de la plus haute qualité. L'article 30(3)(c) oblige ensuite le contrat lui-même, lorsque des fonctions critiques ou importantes sont prises en charge, à exiger que le fournisseur dispose de mesures, d'outils et de politiques de sécurité TIC conformes au cadre réglementaire de l'entité.
Un pipeline de création de fournisseur compromis ou invérifiable est une voie directe vers les préjudices ciblés par ces dispositions. Si le fournisseur ne peut pas indiquer quel artefact exact est exécuté en production, la banque ne peut pas répondre à ses propres obligations de gestion des modifications et de correctifs en vertu de l'article 9(4)(e) et (f) pour la fonction externalisée, ne peut pas établir de rapport d'incident majeur en vertu de l'article 19 to pour les versions concernées et ne peut pas honorer les droits d'audit. L'article 30(3)(e) exige que contrat à accorder. Les preuves de la chaîne d’approvisionnement constituent donc un élément d’évaluation pour l’article 28 file de la banque plutôt que pour le marketing du fournisseur.
| Disposition | Ce qu'elle exige | Ce que le fournisseur fournit |
|---|---|---|
| Article 28(4) | Identification des risques pré-contractuels et diligence raisonnable complète sur le fournisseur potentiel | Un dossier de chaîne d'approvisionnement révisable : construction, signature, vérification, provenance, SBOM, contrôles de libération |
| Article 28(5) | Contracter uniquement avec des fournisseurs répondant aux normes appropriées de sécurité de l'information ; normes de qualité les plus élevées pour les fonctions critiques ou importantes | Conformité du cadre nommé (par exemple, les objectifs de niveau SLSA) avec les artefacts qui la justifient |
| Article 28(3) | Un registre d'informations couvrant tous les accords contractuels TIC | Identifiants stables de service, de composant et de version que la banque peut conserver dans son registre |
| Article 30(3)(c) | Mesures, outils et politiques contractuels de sécurité TIC pour les fonctions critiques ou importantes | Les contrôles de la chaîne d'approvisionnement rédigés sous forme d'engagements contractuels vérifiables |
| Article 30(3)(e) | Droits continus de surveillance, d'accès, d'inspection et d'audit | Commandes de vérification et accès aux preuves qu'un auditeur de banque peut exercer sans l'aide du fournisseur |
| Article 19 | Rapport d'incident majeur lié aux TIC par l'entité financière | Identification exacte de la version affectée à partir des résumés, des SBOM et de la provenance dans les délais de l'incident |
Constructions reproductibles : la même source produit le même résumé
Une construction est reproductible lorsqu'une reconstruction indépendante de la même révision source produit un bit identique. artefact, ce qui pour les images de conteneurs signifie le même résumé d'image. La reproductibilité convertit la « confiance en notre pipeline » en une propriété que tout le monde peut tester. Si une reconstruction à partir de la source publiée produit le résumé en cours d'exécution, alors rien n'a été injecté entre la révision de la source et la production, et aucun indicateur de compilateur non révisé, dérive de dépendance ou correctif manuel ne se trouve à l'intérieur de l'artefact.
L'ingénierie derrière cela est spécifique et vérifiable. Les horodatages de build sont épinglés sur la révision source plutôt que sur l'horloge murale, donc deux builds du même commit intègrent les mêmes heures. Le constructeur lui-même est épinglé par Digest, de sorte que la chaîne d'outils ne peut pas dériver silencieusement. Les horodatages des calques sont réécrits à la valeur épinglée. Les dépendances sont résolues à partir d'un fichier de verrouillage et la construction rejette les entrées non épinglées. Dans le pipeline de versions de KLA, une porte de reproductibilité effectue deux reconstructions propres de chaque image de service propriétaire couverte avec les caches désactivés et fait échouer la publication lorsque les résumés diffèrent, et le résumé de version doit être égal au résumé reconstruit avant la promotion.
Pour un évaluateur DORA, la reproductibilité sous-tend le droit d'audit de l'article 28(6) avec quelque chose de plus fort que les preuves d'entretien : l'audit peut réexécuter la construction. Il donne également le contenu réel de la description du service de l'article 30(2)(a), car « le logiciel que nous fournissons » se résout en un résumé au lieu d'une chaîne de version saisie par un humain.
- Preuve à demander : le résultat du contrôle de reproductibilité pour une version récente montrant que le résumé de reconstruction est égal au résumé de version.
- Preuves à demander : la configuration du pipeline prouvant les horodatages de construction épinglés, les générateurs épinglés par résumé et les dépendances verrouillées.
- Preuve à demander : la déclaration de portée : quelles images sont couvertes par la porte de reproductibilité et quel est le plan pour le reste.
- Drapeau rouge : un fournisseur qui ne peut pas nommer le résumé en cours d'exécution pour son propre service.
Images signées, vérifiées là où cela compte : à l'admission
Une signature sur une image conteneur lie l'artefact à une identité. Cosign de Sigstore est devenu l'outil commun : le pipeline signe le résumé de l'image après la construction, et la vérification vérifie à la fois la signature et l'identité du signataire. La signature sans clé renforce la revendication d'identité, car le certificat est émis en fonction de l'identité OIDC du système CI pour un référentiel et un flux de travail spécifiques, de sorte que la signature affirme « construit par ce pipeline sur cette branche » plutôt que « signé par celui qui détenait un fichier de clé ».
La signature seule est décorative à moins que quelque chose refuse d'exécuter des artefacts non signés. Le point d’application qui compte est l’admission du cluster. Un contrôleur d'admission Kubernetes, Kyverno dans le déploiement de KLA, vérifie la signature sur chaque image propriétaire avant que le pod ne soit admis, résout les balises en résumés immuables afin que ce qui a été vérifié soit ce qui s'exécute et échoue en production : lorsque la politique ne peut pas être évaluée, la charge de travail ne démarre pas. Le déploiement est progressif, avec une observation en mode audit en cours de développement avant l'application dans les espaces de noms de production.
Il s'agit du contrôle qu'une équipe bancaire devrait étudier le plus durement, car il convertit toute l'histoire de la signature du processus en physique. Il correspond également clairement au langage DORA : l'article 9(4)(e) exige des contrôles documentés de gestion des changements garantissant que les modifications apportées aux systèmes TIC sont enregistrées, testées, évaluées, approuvées, mises en œuvre et vérifiées de manière contrôlée, et la vérification du moment de l'admission est l'étape « vérifiée » rendue mécanique. Pour le contrat, il s'agit d'une mesure de sécurité concrète de l'article 30(3)(c) dont la configuration peut être lue par un auditeur.
Les chemins négatifs méritent la même attention. Demandez-vous ce qui se passe lorsque la vérification échoue, lorsque le journal de transparence des signatures est inaccessible et lorsque quelqu'un tente de déployer une image créée en dehors du pipeline sanctionné. Une réponse de qualité bancaire affiche un événement d'admission bloquée et une alerte, et le fournisseur doit être en mesure de démontrer le blocage sur demande. Alerter sur la politique de vérification elle-même, de sorte qu'une politique désactivée silencieusement appelle quelqu'un, ferme la boucle.
Provenance et SBOM : qu'est-ce que c'est et d'où il vient
La provenance est une attestation signée enregistrant la façon dont un artefact a été construit : la révision source, le générateur, le flux de travail et les paramètres de construction. Le framework SLSA standardise le format et définit les niveaux d'intégrité pour le pipeline qui le produit. Une nomenclature logicielle (SBOM) répertorie les composants à l'intérieur de l'artefact dans un format lisible par machine tel que SPDX ou CycloneDX. La provenance répond « qui a construit ceci à partir de quoi » ; le SBOM répond "ce qu'il y a dedans". Un fournisseur sérieux génère les deux dans le pipeline au moment de la construction, les attache à l’image et les signe, de sorte qu’ils partagent les garanties d’intégrité de l’artefact au lieu de vivre dans un wiki.
Pour la banque, le SBOM est ce qui transforme une divulgation de vulnérabilité en une question limitée. Lorsque le prochain CVE critique arrive dans une bibliothèque commune, la banque peut demander au fournisseur quelles versions déployées contiennent le composant concerné et attendre une réponse dérivée des SBOM des résumés en cours, dans les heures qui suivent. Cette capacité alimente les politiques de patch et de mise à jour de l'article 9(4)(f) de la banque pour la fonction externalisée, ainsi que les rapports de l'article 19 incident, dans lesquels le rapport doit préciser quels services et versions ont été affectés. La provenance sert le droit de surveillance de l'article 30(3)(e) : un auditeur détenant l'attestation peut confirmer de manière indépendante que l'artefact en cours d'exécution a été construit par le pipeline sanctionné à partir de la révision indiquée.
Deux questions de suivi séparent les fournisseurs expérimentés de ceux qui aspirent. Tout d’abord, la couverture : des attestations sont-elles produites pour chaque artefact de sortie ou uniquement pour l’image phare ? Deuxièmement, la vérification : est-ce que quelque chose consomme les attestations, ou sont-elles produites et jamais vérifiées ? Produire une provenance que rien ne vérifie a toujours de la valeur pour la criminalistique des incidents, et un fournisseur qui déclare honnêtement cette limite est plus crédible qu'un fournisseur qui implique des contrôles qui n'existent pas.
Un chemin de déverrouillage contrôlé : pas de portes latérales
La question restante est de savoir si les commandes ci-dessus peuvent être contournées. Un chemin de version contrôlé signifie que la route depuis la source fusionnée vers le trafic de production est fermée : chaque image d'exécution est référencée par un résumé immuable plutôt que par une balise mutable, l'état de déploiement est déclaré dans une configuration à contrôle de version (GitOps) afin que les modifications du cluster soient tracées jusqu'aux validations examinées, et les propres dépendances du pipeline CI, y compris les actions CI tierces, sont épinglées aux révisions exactes afin que le système de construction ne puisse pas être modifié en amont de la signature.
L'épinglage du Digest mérite sa propre vérification, car c'est là que les bons pipelines fuient discrètement. Une balise comme « v1.4 » peut être redirigée vers le registre après examen ; un résumé ne le peut pas. Le pipeline de KLA valide que le runtime manifeste les images de référence par résumé et maintient la liste d'exceptions vide ; Les images tierces qui doivent s'exécuter dans le cluster sont mises en miroir, analysées et signées sous la même identité que les images propriétaires, de sorte que la politique d'admission s'applique à tout.
C'est également là que le facteur humain est testé. Demandez qui peut passer directement à la production, selon quelle procédure de bris de vitre et quel bilan laisse un déploiement de bris de vitre. L'article 30(3)(b) exige que le contrat comporte des obligations de notification et de reporting pour les développements qui affectent matériellement la capacité du fournisseur à livrer ; une version d'urgence en dehors du chemin standard est exactement un tel développement, et un fournisseur de niveau bancaire peut montrer la procédure, la piste d'approbation qu'elle produit et comment l'artefact est toujours signé et vérifié même en cas d'urgence.
| Pratique | Preuve qu'un évaluateur peut vérifier | Pertinence DORA |
|---|---|---|
| Constructions propriétaires reproductibles | Reconstruire la transcription montrant l'égalité de résumé pour une version récente ; Configuration du pipeline d'horodatage épinglé et de constructeur épinglé | justifie les normes de sécurité de l'article 28(5) ; rend les audits de l'article 28(6) réexécutables |
| Signature d'image sans clé liée à l'identité du CI | Sortie de la commande de vérification montrant l'identité du signataire liée au flux de travail de libération | Article 30(3)(e) surveillance indépendante ; preuve d'identité pour le registre de l'article 28(3) |
| Vérification de la signature rythmique d'admission, échec fermé en production | La politique d'admission, un déploiement bloqué démontré et l'alerte qu'il a déclenchée | Article 9(4)(e) a vérifié le contrôle des modifications en tant qu'article contractuel 30(3)(c) mesure |
| Attestations de provenance signées (SLSA) | Attestation pour un résumé de production nommant la révision de la source, le constructeur et le flux de travail | Article 30(3)(e) droits d'audit ; analyse approfondie des incidents en vertu de l'article 19 |
| SBOM par artefact de version | Document SPDX ou CycloneDX pour le résumé en cours d'exécution ; une réponse chronométrée à "quelles versions contiennent le composant X" | Alimente les politiques de patch de l'article 9(4)(f) de la banque et l'article 19 incident portant sur la portée |
| Épinglage du résumé et déploiement déclaré par GitOps | Sortie de validation du manifeste ; une liste d'exceptions vide ; modifier l'état du cluster de suivi de l'historique en commits examinés | Article 30(2)(a) description précise du service ; Article 28(4) entrée d'évaluation des risques |
| Dépendances CI épinglées | Fichiers de flux de travail épinglant les actions de tiers et les constructeurs pour exiger des révisions | Réduit l'exposition de la chaîne de sous-traitance. L'article 29(2) exige que la banque pèse |
La liste de contrôle de l'acheteur : questions et à quoi ressemble une bonne réponse
Le tableau ci-dessous représente l'actif à soulever et à utiliser. Posez les questions devant n'importe quel fournisseur d'IA, enregistrez les réponses dans le fichier d'évaluation de l'article 28(4) et traitez la colonne « bonne réponse » comme point d'ancrage de notation. Chaque bonne réponse partage une propriété : elle pointe vers un artefact ou une démonstration plutôt que vers un PDF de politique.
| Question | À quoi ressemble une bonne réponse |
|---|---|
| Pouvez-vous reconstruire une image de production à partir de la source et obtenir le même résumé ? | Oui, avec une transcription de reconstruction récente. Le fournisseur nomme les images couvertes et indique le plan pour le reste. |
| Quel résumé est actuellement en cours d'exécution pour votre service et comment le savez-vous ? | Un résumé lu à partir de l'état de déploiement, mis en correspondance avec un enregistrement de version, en minutes. L’hésitation ici sape toute autre réponse. |
| Comment les images sont-elles signées et quelle identité la signature revendique-t-elle ? | Signature au niveau Digest avec le certificat lié à l'identité du flux de travail CI et la commande de vérification exacte qu'un tiers peut exécuter. |
| Qu'est-ce qui refuse d'exécuter une image non signée ou mal signée ? | Un contrôleur d'admission vérifiant les signatures avant le démarrage des pods, appliquant et échouant la fermeture en production, avec un déploiement bloqué démontré. |
| Que se passe-t-il lorsque l'infrastructure de vérification des signatures est en panne ? | Une posture de fermeture en cas de panne déclarée pour l'admission en production, le repli opérationnel et l'alerte qui se déclenche. Le compromis est compris et possédé. |
| Produisez-vous des attestations de provenance et puis-je en vérifier une ? | Provenance SLSA signée par version nommant la révision source, le générateur et le flux de travail, avec la commande de vérification incluse. |
| Pouvez-vous me donner un SBOM pour la version exacte que nous exécuterions ? | Un SBOM lisible par machine généré au moment de la construction pour ce résumé, plus un délai d'exécution engagé pour les questions d'exposition des composants. |
| Vos images d'exécution sont-elles référencées par une balise ou un résumé ? | Digest partout, imposé par une vérification du pipeline, avec la liste d'exceptions vide ou courte et justifiée. |
| Comment les images tierces et les dépendances CI bénéficient-elles du même traitement ? | Images de tiers mises en miroir, numérisées et signées sous la propre identité du fournisseur ; Actions et constructeurs CI épinglés sur des révisions exactes. |
| Qui peut déployer en production en dehors du chemin standard, et quelle trace cela laisse-t-il ? | Une procédure de bris de glace nommée avec les approbations enregistrées, les artefacts toujours signés et vérifiés et l'événement à signaler à la banque. |
| Lorsqu'une CVE critique survient, à quelle vitesse pouvez-vous me dire si nous sommes exposés ? | Un calendrier engagé, répondu à partir des SBOM des résumés en cours, conforme aux obligations de préavis du contrat. |
| Allez-vous insérer ces contrôles dans le contrat ? | Oui : les pratiques ci-dessus sont écrites sous la forme d'engagements au titre de l'article 30(3) avec droits d'audit, plutôt que référencées comme un document de politique modifiable. |
Lecture des réponses : notation et suivi du contrat
La notation est simple. Une réponse appuyée par un artefact que la banque peut vérifier a obtenu tous les points. Une réponse décrivant un contrôle réel sans preuve indépendante obtient un score partiel et génère une demande de preuve. Une réponse qui redirige vers une certification obtient un score de zéro pour cette liste de contrôle : un SOC 2 report atteste de la période d'audit et des contrôles concernés, et il prouve rarement la reproductibilité, l'application de l'admission ou la provenance de l'artefact spécifique que la banque gérera. Les certifications complètent les preuves au niveau des artefacts ; ils ne le remplacent pas.
Les déclarations de limites honnêtes devraient obtenir des résultats, et cela va dans les deux sens. KLA publie ses propres limites sur le Trust Center, y compris quels contrôles sont appliqués aujourd'hui et lesquels sont mis en place, car un fournisseur prétendant qu'un pipeline parfait décrit un pipeline que personne n'a inspecté. Attendez-vous à des lacunes de couverture ; jugez si le vendeur sait où ils se trouvent, les surveille et séquence la fermeture.
Déplacez ensuite les résultats dans le contrat. L'article 30(1) exige que le contrat complet soit présenté dans un seul document écrit ; L'article 30(2)(b) exige que les lieux de traitement et de stockage soient informés à l'avance des modifications ; L'article 30(3)(e) exige des droits d'accès, d'inspection et d'audit sans restriction pour les fonctions critiques ou importantes. Les pratiques de la chaîne d'approvisionnement vérifiées lors de la diligence raisonnable deviennent le contenu concret de la clause des mesures de sécurité de l'article 30(3)(c), et les commandes de vérification deviennent le mécanisme par lequel la banque exerce ses droits de surveillance sans programmer d'appel au fournisseur. L'article 28(8) exige des stratégies de sortie ; des constructions reproductibles et des SBOM complets réduisent considérablement le risque de sortie, car la banque sait exactement ce qu’elle faisait au moment de son départ.
Pour les équipes évaluant spécifiquement KLA : les réclamations permanentes relatives à la chaîne d'approvisionnement sont disponibles sur la page Sécurité, les réponses préalables à l'examen et les divulgations des sous-traitants ultérieurs sur le Trust Center et le contexte bancaire dans Solutions pour les services financiers. Sources : source source source
Foire aux questions
Un fournisseur d'IA est-il un fournisseur de services tiers TIC sous DORA ?
L'article 3(19) du règlement (UE) 2022/2554 defin définit un fournisseur de services TIC tiers en tant qu'entreprise fournissant des services TIC, et l'article 3(21) définit les services TIC au sens large comme des services numériques et de données fournis via des systèmes TIC de manière continue. Un fournisseur d’IA fournissant un service logiciel hébergé ou déployé relève de cette définition, ainsi que des obligations de diligence raisonnable, d’enregistrement et de contrat de la banque énoncées dans les articles 28 through 30 apply de l’accord.
DORA exige-t-il que les fournisseurs aient des versions reproductibles ou des images signées ?
Aucune disposition ne nomme ces techniques. DORA exige que l'entité financière fasse preuve de diligence raisonnable et d'évaluation des risques avant de contracter (article 28(4)), qu'elle contracte uniquement avec des fournisseurs répondant aux normes de sécurité de l'information appropriées (article 28(5)), et qu'elle engage les fournisseurs prenant en charge des fonctions critiques ou importantes à des mesures, outils et politiques contractuels de sécurité des TIC (article 30(3)(c)). Les versions reproductibles, les images signées vérifiées à l'admission, la provenance et les SBOM sont actuellement les preuves les plus solides qu'un fournisseur puisse offrir contre ces tests.
Quelles preuves de chaîne d'approvisionnement une banque devrait-elle demander à un fournisseur d'IA ?
Une transcription de reconstruction démontrant la reproduction à l'identique du résumé pour une version récente, la commande de vérification de signature avec l'identité du signataire liée au CI, la politique d'admission qui bloque les images non vérifiées avec un bloc démontré, une attestation de provenance signée pour un résumé de production, un SBOM lisible par machine pour la version exacte à exécuter, la validation d'épinglage du résumé pour les manifestes d'exécution et la procédure de bris de verre avec la trace qu'elle laisse.
Pourquoi la vérification de l'heure d'admission est-elle plus importante que la signature elle-même ?
Une signature que rien ne vérifie ne change aucun résultat. La vérification au moment de l'admission effectue la vérification au moment où une charge de travail démarre, de sorte qu'un artefact non signé ou mal signé ne peut pas être exécuté en production, peu importe qui l'a poussé ou pourquoi. Il donne également à la banque un point de contrôle unique et vérifiable : la configuration de la politique, les événements d'admission bloquée et les alertes sur la politique elle-même.
Comment les preuves de la chaîne d'approvisionnement sont-elles liées aux rapports d'incidents DORA ?
L'article 19 requioblige les entités financières à signaler les incidents majeurs liés aux TIC à leur autorité compétente. La portée d'un tel rapport pour un service d'IA externalisé dépend de la connaissance exacte des versions d'artefact affectées. Les déploiements épinglés par Digest, les SBOM et la provenance permettent au fournisseur de répondre en quelques heures, ce dont la banque a besoin pour respecter ses propres délais de reporting et pour satisfaire aux obligations de notification écrites dans le contrat en vertu de l'article 30(3)(b).
Points clés à retenir
Une chaîne d'approvisionnement de fournisseur d'IA de niveau bancaire est démontrée avec des artefacts : une reconstruction qui reproduit le résumé de production, une signature liée à l'identité du pipeline, un contrôleur d'admission qui bloque tout le reste, la provenance et un SBOM pour chaque version, et un chemin fermé de la source examinée à la charge de travail en cours d'exécution. DORA donne à la banque acheteuse à la fois le mandat et le vocabulaire nécessaires pour exiger ces preuves avant de signer, et elle donne aux fournisseurs sérieux un moyen de se différencier visiblement des fournisseurs disposant d'un PDF de politique. Utilisez la liste de contrôle ci-dessus lors de la prochaine évaluation, lisez les affirmations de KLA sur la page Sécurité et le Trust Center, et placez la conversation avec le fournisseur dans le cadre plus large du contrôle avec le Guide de gouvernance de l'IA dans le secteur bancaire et Solutions pour les services financiers.