Une banque qui utilise un outil d’IA dans une décision de crédit doit le documenter trois fois : pour l’AI Act, pour DORA et pour son délégué à la protection des données. L’essentiel de cette documentation dépend d’une question : que détient le fournisseur, et qu’opère-t-il ? Si la réponse est rien, la banque documente des faits sur sa propre infrastructure. Si le fournisseur héberge le système, elle documente des clauses dans le contrat d’un tiers.

La banque est le déployeur

L’AI Act classe à haut risque tout système d’IA utilisé pour évaluer la solvabilité de personnes physiques ou établir leur note de crédit, hors détection de fraude.[1] La banque qui exploite un tel système en est le déployeur. L’article 26 précise ce que cela implique : utiliser le système conformément à la notice du fournisseur, confier le contrôle humain à des personnes qui ont la compétence, la formation et l’autorité nécessaires, surveiller son fonctionnement, et conserver les journaux qu’il génère au moins six mois, lorsque ces journaux sont sous son contrôle.[2]

Le fournisseur doit le reste. L’article 12 impose à un système à haut risque d’enregistrer automatiquement les événements tout au long de son cycle de vie, et l’article 13 de l’accompagner d’une notice d’utilisation.[3] Le dossier du déployeur commence donc par deux documents du fournisseur : la notice, et la description de ce que le système enregistre et où.

« Sous leur contrôle »

L’article 26 demande au déployeur de conserver les journaux dans la mesure où ils sont sous son contrôle.[2:1] Tout le dossier repose sur cette clause. Si les journaux sont dans le cloud du fournisseur, le contrôle de la banque tient à un contrat. S’ils sont sur ses propres serveurs, la banque peut les montrer au superviseur sans rien demander à personne.

Les journaux doivent aussi avoir le bon contenu. Un enregistrement des prompts et des réponses du modèle montre ce que le modèle a dit. Un superviseur qui demande pourquoi un prêt a été refusé a besoin de savoir ce qui a été fait : quelles données ont été lues, quelle règle s’est appliquée, qui a validé. Une trace qu’on peut rejouer est une preuve. Une trace qu’on peut seulement lire est un récit.

Le contrôle humain exige un nom

L’article 26 impose un contrôle par des personnes physiques dotées d’autorité.[2:2] Quelqu’un qui valide plusieurs centaines de propositions de la machine par jour ne contrôle rien.[4] Le contrôle que la banque documente doit être une personne nommée, qui a l’autorité de refuser une proposition et le temps de l’examiner.[5]

Si le système attache un nom à chaque action par construction, la section sur le contrôle humain décrit simplement son fonctionnement. Si les noms sont ajoutés après coup par une procédure de revue, le superviseur demandera combien de fois cette procédure est sautée.

DORA : le registre, le contrat, la sortie

DORA impose aux entités financières de gérer le risque lié aux prestataires TIC tiers et de tenir un registre de tous les accords contractuels portant sur des services TIC fournis par un tiers.[6] Ces contrats doivent préciser où le service est fourni et où les données sont traitées et stockées, les droits d’accès, d’inspection et d’audit de l’entité, et les droits de résiliation avec une stratégie de sortie.[7]

Pour un service d’IA hébergé, chacune de ces dispositions se négocie, car chacune porte sur quelque chose que le fournisseur détient. Pour un logiciel que la banque installe et exploite sur sa propre infrastructure, l’entrée au registre existe toujours et la fonction conformité décide de sa qualification. Le contenu est plus simple. Les données sont dans le datacenter de la banque. Le droit d’audit est exercé par ses propres équipes sur ses propres journaux. La stratégie de sortie est triviale, car le logiciel continue de fonctionner si le fournisseur disparaît.

Les fournisseurs d’infrastructure arrivent aux mêmes conclusions. Cockroach Labs soutient que la base de données sous un agent IA doit offrir un stockage d’audit en ajout seul, l’attribution des identités et le contrôle de la résidence des données avant le déploiement, car rien de tout cela ne s’ajoute après coup pour un examinateur.[8] Teleport soutient que les systèmes agentiques exigent des événements d’audit liés à une identité unique et immuable pour chaque action, et qu’une documentation statique ne vaut pas preuve.[9]

RGPD : le DPO tranche

Lorsqu’un fournisseur traite des données personnelles pour le compte de la banque, l’article 28 du RGPD impose un contrat comportant des clauses précises.[10] Un logiciel que la banque installe et exploite elle-même, sans que le fournisseur détienne de données, relève d’une autre situation. Le délégué à la protection des données tranche, sur une question : le fournisseur détient-il, reçoit-il ou accède-t-il jamais aux données ? Un bon fournisseur donne une réponse que le DPO peut vérifier depuis le réseau de la banque.

Qui écrit quoi

  • Notice d’utilisation et description de l’enregistrement. Fournies par le fournisseur, conservées par le déployeur.[3:1]
  • Contrôle humain. Rédigé par le déployeur : un nom par décision, avec l’autorité de refuser.[2:3]
  • Journaux. Enregistrés par le système, conservés par le déployeur lorsqu’ils sont sous son contrôle.[2:4]
  • Entrée au registre, localisation des données, droits d’audit, stratégie de sortie. Rédigés par le déployeur ; leur contenu dépend de l’endroit où tourne le logiciel.[6:1]
  • Analyse article 28. Le DPO.[10:1]

Chacune de ces parties s’écrit plus vite quand le fournisseur ne détient aucune donnée, n’opère rien, et que chaque action porte un nom. L’auditabilité est un avantage concurrentiel : ce que le marché exigera d’ici cinq ans peut être proposé dès aujourd’hui.[11]

Notre position

Galahad n’héberge pas vos données et n’opère aucun plan de contrôle dont votre déploiement dépendrait. Nous ne prétendons pas porter votre conformité à votre place : le dossier appartient au déployeur. Monarch tourne dans votre infrastructure et votre juridiction, dans le périmètre de votre homologation, et il est conforme au RGPD et à l’AI Act.

Venez à la démonstration avec votre DPO et votre registre DORA. Voyez-le sur vos données.

  1. Règlement (UE) 2024/1689, annexe III, point 5, b). Source ↩︎

  2. Règlement (UE) 2024/1689, article 26, obligations incombant aux déployeurs de systèmes d’IA à haut risque. Source ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. Règlement (UE) 2024/1689, article 12, enregistrement, et article 13, transparence et fourniture d’informations aux déployeurs. Source ↩︎ ↩︎

  4. Machines de conséquence, thèse 8. Le lire ↩︎

  5. Machines de conséquence, thèse 11. Le lire ↩︎

  6. Règlement (UE) 2022/2554, article 28, principes généraux du risque lié aux tiers prestataires de services TIC, dont le registre d’informations. Source ↩︎ ↩︎

  7. Règlement (UE) 2022/2554, article 30, principales dispositions contractuelles. Source ↩︎

  8. Cockroach Labs, « DORA Compliance for AI Agents: Database Requirements Before Deployment ». Source ↩︎

  9. Teleport, « Guide: DORA Compliance Evidence for Agentic AI ». Source ↩︎

  10. Règlement (UE) 2016/679, article 28, sous-traitant. Source ↩︎ ↩︎

  11. Machines de conséquence, thèse 47. Le lire ↩︎