Déontologie juridique américaine et IA générative — ABA Formal Opinion 512 (29 juillet 2024) et les Model Rules qu'elle applique
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.
Les avis de l'ABA sont consultatifs. Ils ne lient un avocat que dans la mesure où l'État de cet avocat adopte la règle ou la position concernée. Les durées de conservation des dossiers clients sont fixées État par État ; la Model Rule 1.15 indique cinq ans entre crochets pour les registres de fonds de tiers, à titre de valeur indicative. Aucun avis formel ultérieur de l'ABA sur l'IA n'avait été publié en septembre 2026.
La table d'exigences
10 lignes : 5 mécanismes, 4 organisationnelles, 1 lacune nommée
| Exigence | Mécanisme, obligation ou lacune | Type |
|---|---|---|
| Model Rule 1.1 — compétence : comprendre ce que l'outil d'IA peut et ne peut pas faire, et tenir cette compréhension à jour | organisationnel : la compréhension appartient à l'avocat. Les indications de l'enregistrement sur ce que l'agent n'a pas pu vérifier, et notre mesure des cas où les modèles manquent leurs propres erreurs, y contribuent, sans s'y substituer. | organisationnel |
| Model Rule 1.6 — protéger les informations des clients utilisées avec des outils d'IA | enregistrements scellés sur les propres machines du cabinet, sous sa clé, sans copie côté fournisseur ; chaque lecture, exportation et suppression journalisée ; effacement cryptographique avec un marqueur de suppression qui prouve que l'enregistrement a existé | mécanisme |
| Model Rule 1.6 — consentement éclairé du client avant que des informations confidentielles n'entrent dans un outil auto-apprenant | organisationnel : c'est à l'avocat d'obtenir le consentement, et l'Opinion 512 indique qu'une clause type dans une lettre de mission ne suffit pas | organisationnel |
| Model Rules 3.1, 3.3 et 8.4(c) — résultats de l'IA vérifiés avant de parvenir à une juridiction | les chiffres et les citations de chaque exécution sont rapprochés des sources qu'ils invoquent ; des constats sont soulevés et les exécutions signalées pour revue ; la contre-signature d'un réviseur nommément désigné est scellée à côté de l'exécution. La vérification elle-même appartient à l'avocat. | mécanisme |
| Model Rules 5.1 et 5.3 — supervision des avocats, du personnel et des prestataires qui utilisent l'IA | qui a revu quelle exécution, et quand, figure dans la chaîne à côté de l'exécution ; les retenues d'actions irréversibles montrent ce qui a été arrêté pour décision. Les politiques de supervision appartiennent au cabinet. | mécanisme |
| Model Rules 1.4 et 1.5 — informer les clients de l'usage de l'IA, et honoraires raisonnables pour un travail assisté par l'IA | organisationnel : l'information des clients et l'appréciation en matière de facturation appartiennent à l'avocat. Les horodatages de l'enregistrement scellé peuvent étayer une question de facturation ; ils n'y répondent pas. | organisationnel |
| Model Rule 1.16(d) — remettre au client, à la fin de la représentation, les pièces et biens auxquels il a droit | exportation complète de chaque enregistrement à tout moment, avec la chaîne pour montrer que l'exportation est complète pour sa période | mécanisme |
| Formal Opinion 520 (janvier 2026) — répondre aux demandes d'information d'un ancien client ou de l'avocat qui lui succède, qui peuvent porter sur des informations jamais consignées par écrit | organisationnel : décider de ce dont un ancien client ou l'avocat successeur a besoin, et transmettre ce qui n'a jamais été enregistré, appartient à l'avocat. Les enregistrements scellés ne peuvent fournir que ce qui a été capturé. | organisationnel |
| Conservation des dossiers clients et des registres de fonds de tiers (règles des États) | dates de conservation par enregistrement, fixées lors du scellement (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 |
| Recours aux enregistrements de cet outil comme preuves — é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.