Règles FINRA appliquées à l'IA générative et aux agents d'IA — courtiers en valeurs mobilières (broker-dealers)
Cette page est générée à partir de la table d'exigences que le moteur AiSSAY livre pour ce référentiel. Quand le moteur produit un dossier de preuves, chaque ligne ci-dessous reçoit un statut calculé à partir des propres enregistrements de l'opérateur à ce moment-là. Cette page montre la table, pas les résultats de qui que ce soit.
Mise en correspondance à titre informatif, établie par les propres outils de l'opérateur. Ce n'est ni un avis juridique, ni une certification, ni un substitut au conseil d'un avocat. Elle organise les enregistrements de l'opérateur au regard des exigences citées ; la question de savoir si ces enregistrements satisfont aux exigences relève de l'appréciation de l'opérateur, de son conseil juridique et du contrôleur.
La Regulatory Notice 24-09 (27 juin 2024) indique que les règles existantes s'appliquent à l'IA générative et ne crée aucune exigence nouvelle. Les pratiques relatives aux agents d'IA du 2026 Annual Regulatory Oversight Report sont des orientations, pas des règles. La Notice 26-14 (juillet 2026), sur la supervision des communications destinées aux particuliers, y compris celles générées par l'IA, était encore une proposition en septembre 2026. La SEC Rule 17a-4 a sa propre vue.
La table d'exigences
8 lignes : 6 mécanismes, 1 organisationnelle, 1 lacune nommée
| Exigence | Mécanisme, obligation ou lacune | Type |
|---|---|---|
| Rule 4511 — établir et conserver des livres et registres ; six ans lorsqu'aucune durée n'est précisée | dates de conservation par enregistrement (sept ans par défaut) ; la suppression avant cette date est refusée sans dérogation consignée ; une mesure de conservation à des fins juridiques (legal hold) bloque purement et simplement la suppression | mécanisme |
| Rule 3110(a) — un système de supervision raisonnablement conçu pour assurer la conformité | organisationnel : les procédures de supervision écrites appartiennent à l'entreprise. L'enregistrement atteste ce que la supervision a vu et fait. | organisationnel |
| Rule 3110(b)(4) — revue de la correspondance par un principal, attestée par écrit avec le nom du réviseur et la date | la contre-signature d'un réviseur nommément désigné est scellée à côté de l'exécution avec sa date ; les lectures des réviseurs sont journalisées avec attribution | mécanisme |
| Rule 2210 — communications, y compris celles générées par l'IA : approbation lorsqu'elle est requise, contenu loyal et équilibré, conservation avec les dates | le résultat produit par un agent est scellé mot pour mot avec son exécution ; les envois irréversibles sont retenus jusqu'à ce que la politique de l'entreprise réponde, et la décision est consignée comme une étape. Le caractère loyal et équilibré du contenu relève du jugement de l'entreprise. | mécanisme |
| Regulatory Notice 24-09 — protéger les informations des clients lors de l'utilisation de l'IA générative | enregistrements scellés sur les propres machines de l'entreprise, sous sa clé, sans copie côté fournisseur ; chaque lecture, exportation et suppression journalisée | mécanisme |
| 2026 Oversight Report (orientations) — pour les agents d'IA, garder un humain dans la boucle, suivre les actions et les décisions, conserver les journaux des prompts et des résultats | chaque appel d'outil, décision et résultat est enregistré pour chaque exécution ; les actions irréversibles attendent la réponse d'un humain ; les constats et les retenues figurent dans l'enregistrement | mécanisme |
| 2026 Oversight Report (orientations) — suivre la version du modèle utilisée par un agent | chaque enregistrement porte deux champs de modèle, jamais fusionnés : la chaîne de modèle indiquée par la propre réponse de l'API du fournisseur, capturée par le proxy d'enregistrement ou par le code qui a reçu la réponse, et le modèle déclaré par l'intégrateur. Le dossier compte les deux catégories séparément et compte les exécutions qui n'enregistrent ni l'un ni l'autre. Le modèle n'est jamais déduit de la manière dont se lit le résultat. | mécanisme |
| Recours à cet outil — évaluation indépendante de ses contrôles | NON IMPLÉMENTÉ. Il n'existe encore ni test d'intrusion, ni revue de la cryptographie par un tiers, ni rapport indépendant sur les contrôles de ce logiciel. Quiconque s'appuie sur ces enregistrements comme preuves doit évaluer l'outil lui-même, et cette ligne le dit en premier. | lacune nommée |
Comment un statut s'obtient
- Étayé
- une vérification déterministe a été exécutée sur vos enregistrements et les décomptes étayent la ligne. Un stockage ne contenant aucun enregistrement pertinent apparaît comme non étayé — une affirmation vraie, pas une validation. Vide ne compte jamais comme conforme.
- Délégué
- le mécanisme est appliqué par un système auquel vous faites déjà confiance — un stockage scellé par votre propre gestionnaire de clés lui délègue le contrôle d'accès, et le dossier indique que le journal qui fait foi est celui de votre gestionnaire de clés, pas le nôtre. Le dossier nomme le point de terminaison par lequel le gestionnaire de clés a été joint. Un point de terminaison AWS autre que celui qu'AWS utilise par défaut pour la région apparaît comme délégué à ce point de terminaison, avec une demande de confirmation qu'il s'agit bien de votre service de gestion des clés. Un seul backend — AWS KMS — a été exécuté sur le service AWS KMS réel ; aucun autre backend ne l'a été.
- Point d'intégration de test
- scellé par un backend de test interne au processus — un bouchon (stub), ou un substitut du client AWS — et le statut précise lequel. Aucun gestionnaire de clés n'applique le contrôle d'accès. Le point d'intégration est construit et testé, et le dossier refuse d'appeler cela une délégation.
- Partiellement étayé
- le mécanisme est construit et certaines de vos exécutions en portent la preuve, mais pas toutes — généralement parce qu'elles ont été scellées avant que le mécanisme n'existe. Le dossier indique combien d'exécutions se trouvent dans chaque groupe, et ne compte jamais celles qui manquent comme validées.
- Organisationnel
- l'exigence est une procédure que seules des personnes peuvent accomplir. Le dossier la désigne comme la vôtre au lieu de déguiser une politique en mécanisme.
- Lacune nommée
- le dossier ne peut pas l'étayer — soit le mécanisme n'est pas construit, soit aucun logiciel ne peut le fournir — et il précise lequel des deux. La lacune est imprimée, parce qu'un examinateur doit la lire ici plutôt que la découvrir.
Aucun statut n'est saisi à la main : chaque statut est recalculé à partir du stockage chaque fois qu'un dossier est produit, le texte des exigences et des mécanismes est rédigé et relu dans le cadre du moteur, et les preuves relatives aux dépendances proviennent de notre analyse de version. Un mécanisme en échec ne peut jamais être lu comme la preuve que le contrôle fonctionne.