D5 · Governance, Safety & Risk Management

Ce domaine pèse 14 % – environ 9 des 63 items. Il teste si vous savez rendre un système Claude sûr, conforme et défendable dans une entreprise réglementée. Les jugements récurrents : appliquer la sûreté en couches (non par une seule règle de prompt), placer des points de contrôle humains sur les actions irréversibles/réglementées, et accorder le traitement des données à la réglementation applicable (GDPR/HIPAA/FedRAMP/SOC 2/EU AI Act) plutôt qu’à la commodité.

Objectifs d’apprentissage

À la fin de cette page, vous devriez savoir :

Concevoir des garde-fous en couches (défense en profondeur).
Raisonner avec une taxonomie des modes de défaillance des LLM.
Placer les points de contrôle de supervision humaine (human-in-the-loop) et concevoir l’UX d’approbation et l’audit.
Cartographier les déploiements aux cadres réglementaires : GDPR (DSAR, DPIA, résidence), HIPAA (BAA, PHI), FedRAMP High, SOC 2, EU AI Act.
Choisir la posture de rétention des données, y compris le Zero Data Retention et l’exigence de rétention 30 jours de Fable 5.1.
Appliquer les principes d’IA éthique (biais, équité, transparence, explicabilité, divulgation).
Mener l’évaluation du risque / la gestion du risque modèle, la réponse aux incidents, et le red-teaming dans le cadre de la politique d’usage acceptable.

5.1 Garde-fous en couches (défense en profondeur)

Aucun contrôle unique ne suffit. La sûreté vient de couches indépendantes, pour qu’un contournement de l’une soit rattrapé par la suivante.

Couche	Applique	Force
Classifieur d’entrée	Filtrer l’injection de prompt, les PII, le contenu interdit	Probabiliste
Règles du system prompt	Orientation comportementale	Douce — peut être contournée
Hooks de permission d’outil	Règles métier/d’autorisation fermes	Déterministe (le code de sortie 2 bloque)
Validation de sortie	Vérifications de schéma, sûreté, politique	Déterministe
Revue humaine	Jugement sur le fort enjeu/l’irréversible	La plus forte, la plus lente

Le prompt n’est pas un garde-fou

Une phrase du system prompt est la couche 2 — de l’orientation, non de l’application. Les règles fermes (plafonds de dépense, suppressions, accès aux données) appartiennent aux hooks et à la validation (anti-patron n° 3). Toute réponse qui repose uniquement sur la formulation du prompt pour appliquer une règle critique est fausse.

5.2 LLM failure-mode taxonomy

Mode de défaillance	Ce que c’est	Contrôle principal
Hallucination	Contenu fluide, non soutenu	Grounding, citations, validation
Injection de prompt (directe)	L’utilisateur écrase les instructions	Classifieur d’entrée, séparation privilégiée/instruction
Injection de prompt (indirecte)	Instructions malveillantes dans les résultats d’outils/docs/web	Traiter le contenu externe comme non fiable ; assainir ; moindre privilège
Jailbreak	Contourner la politique de sûreté	Classifieurs en couches, comportement de refus
Exfiltration de données	Soutirer des secrets/PII	Minimisation des PII, filtrage de sortie, pas de secrets dans le contexte
Agence excessive	L’agent fait plus que prévu	Moindre privilège, points de contrôle humains, idempotence
Complaisance (sycophancy)	Approuve l’utilisateur quelle que soit la vérité	Prompting neutre, revue indépendante

Signal d’examen

« Un document/résultat d’outil contient des instructions cachées » → injection de prompt indirecte ; le correctif est de traiter le contenu externe comme des données non fiables et d’appliquer le moindre privilège, non de lui faire confiance parce qu’il vient d’un outil.

5.3 Human-in-the-loop design

La revue humaine est obligatoire pour les actions irréversibles, réglementées, externes, ou portant des données personnelles. L’architecte décide où va le point de contrôle, ce que voit le relecteur, et comment il est audité.

Question de conception	Recommandation
Où va le point de contrôle ?	Juste avant l’action irréversible/réglementée (paiement, suppression, publication, sortie clinique/juridique)
Que voit le relecteur ?	L’action proposée, les preuves/citations, et la confiance — assez pour juger, non pour tamponner
Comment l’escalade est-elle déclenchée ?	Sur la complexité/le risque de la tâche, non sur le sentiment ni sur la confiance auto-déclarée
Comment est-elle auditée ?	Journal immuable de qui a approuvé quoi, quand, avec les entrées et la version du modèle

Anti-patrons d’escalade

N’escaladez pas en fonction du sentiment (sentiment ≠ complexité, anti-patron n° 5) ni de la confiance auto-déclarée (anti-patron n° 4). Escaladez sur des signaux de complexité/risque mesurés ou des règles déterministes.

5.4 Regulatory compliance

Cadre	Obligations centrales	Implications d’architecture
GDPR	Base légale ; DSAR (accès/effacement/rectification) ; DPIA pour le traitement à haut risque ; résidence des données	Placement en région UE (Vertex/Bedrock UE) ; chemin de suppression ; limites de minimisation/rétention ; DPIA avant le lancement
HIPAA	BAA avec le fournisseur ; protéger les PHI ; minimum nécessaire	Signer un BAA ; contrôles de traitement des PHI ; posture ZDR/rétention ; logs d’audit
FedRAMP High	Environnement fédéral américain autorisé	Déployer via Bedrock/Vertex dans le périmètre FedRAMP High (non l’API directe)
SOC 2	Contrôles de sécurité/disponibilité/confidentialité, audités	Hériter des contrôles du fournisseur ; documenter les vôtres
EU AI Act	Obligations par palier de risque ; transparence ; devoirs des systèmes à haut risque	Classer le palier de risque du système ; divulgation ; supervision humaine ; documentation

Signal d’examen

« Fédéral américain / FedRAMP High » → Bedrock ou Vertex dans le périmètre FedRAMP, jamais l’API directe. « Santé / PHI » → BAA + contrôles PHI + rétention. « Données personnelles UE / droit à l’effacement » → GDPR : DPIA, résidence UE, chemin de suppression.

5.5 Data retention and Zero Data Retention

Posture	Ce que cela signifie	Contrainte
Rétention standard	Le fournisseur peut retenir les entrées/sorties selon sa politique pour une durée	Par défaut
Zero Data Retention (ZDR)	Entrées/sorties non retenues au-delà du traitement de la requête	Disponible pour les modèles/entreprises éligibles — pas pour Fable 5.1
Fable 5.1	Requiert une rétention de 30 jours ; non éligible au ZDR ; pas dans le Priority Tier	Si une charge impose le ZDR, n’utilisez pas Fable 5.1

Fable 5.1 vs une exigence ZDR

Si une exigence de conformité impose le ZDR (p. ex. certaines données réglementées), Fable 5.1 est disqualifié car il requiert une rétention de 30 jours. Choisissez plutôt Opus 5 / Sonnet 5 avec ZDR. C’est un piège d’examen direct.

5.6 Ethical AI

Principe	Pratique
Biais & équité	Évals stratifiées par groupe protégé ; traitement symétrique ; revue humaine des décisions à fort impact
Transparence	Documenter les sources de données, les versions de modèle et les limites connues
Explicabilité	Citer les sources ; montrer le raisonnement quand c’est approprié ; rendre les décisions auditables
Divulgation	Dire aux utilisateurs qu’ils interagissent avec une IA quand c’est requis ; étiqueter le contenu généré par IA
Dignité humaine	Garder les décisions conséquentes (recrutement, crédit, clinique) sous autorité humaine

5.7 Risk assessment and model risk management (MRM)

Traitez le système d’IA comme un risque géré, non une boîte noire.

Élément de MRM	Pratique
Classement du risque	Classer par rayon d’impact, réversibilité, réglementation, sensibilité des données
Cartographie des contrôles	Cartographier chaque risque vers une couche de garde-fou / un point de contrôle humain
Inventaire des modèles	Suivre les IDs de modèle, versions, prompts, scores d’éval, propriétaires
Contrôle du changement	Relancer les régressions et réévaluer le risque à tout changement de modèle/prompt
Supervision	Métriques online, détection de dérive, déclencheurs d’incident

5.8 Incident response for AI systems

Déclencheurs : pic de métrique de sûreté, alerte d’exfiltration, détection d’injection, plainte en aval, anomalie de coût. Les IDs de corrélation et les traces (D3) rendent un incident reconstructible.

5.9 Acceptable use and red-teaming

Opérez dans le cadre des termes d’usage acceptable / de la Usage Policy d’Anthropic ; les usages interdits sont hors périmètre quelle que soit la faisabilité technique.
Red-teaming : attaquez proactivement votre propre système — injection de prompt (directe et indirecte), jailbreaks, exfiltration, sondes d’agence excessive — avant que les adversaires ne le fassent. Réinjectez les constats dans la suite de régression et les couches de garde-fous.
Les secrets vivent dans les env / gestionnaires de secrets, jamais dans les prompts, CLAUDE.md, ou les logs. Journalisez sans secrets ni PII.

5.10 Cartographie des contrôles de conformité (contrôles techniques par cadre)

L’examen teste si vous savez cartographier une réglementation vers le contrôle d’architecture précis qu’elle exige, non seulement la nommer.

Exigence dans l’énoncé	Cadre	Contrôle d’architecture concret
« données personnelles de résidents UE », « droit à l’effacement »	GDPR	Placement en région UE (Vertex/Bedrock/Foundry UE) ; pipeline DSAR/effacement ; DPIA avant le lancement ; limites de rétention ; base légale
« traitement à haut risque de données personnelles »	GDPR	DPIA obligatoire comme critère de sortie du design-gate
« dossiers patients », « PHI », « clinique »	HIPAA	BAA signé ; accès au minimum nécessaire ; logs d’audit ; chiffrement ; posture rétention/ZDR
« agence fédérale américaine », « FedRAMP High »	FedRAMP High	Déployer via Bedrock/Vertex dans le périmètre autorisé ; non l’API directe
« rapport SOC 2 », « preuves pour l’auditeur »	SOC 2	Hériter des contrôles du fournisseur ; documenter vos propres contrôles d’accès/changement/supervision
« système d’IA classé haut risque », « transparence envers les utilisateurs »	EU AI Act	Classement du palier de risque ; divulgation à l’utilisateur ; supervision humaine ; documentation technique et journalisation
« aucune donnée retenue au-delà du traitement de la requête »	ZDR	Modèle éligible au ZDR (Opus 5 / Sonnet 5) — jamais Fable 5.1 (rétention 30 jours)

Où chaque contrôle réside dans la conception

Signal d’examen

Accordez le mot-signal au contrôle : « FedRAMP » → périmètre Bedrock/Vertex ; « PHI » → BAA + contrôles PHI ; « effacement/résidents UE » → GDPR DPIA + résidence + chemin de suppression ; « ZDR imposé » → pas Fable 5.1. Les réponses qui satisfont la réglementation avec une règle de prompt ou un choix de commodité sont fausses.

5.11 Un registre des risques pour un déploiement Claude

Un registre des risques est l’artefact qui transforme « cela pourrait mal tourner » en risque assumé et atténué. Cotez la vraisemblance × l’impact, assignez un propriétaire, et cartographiez chaque risque vers une couche de garde-fou.

ID	Risque	Vraisemblance	Impact	Atténuation (couche)	Propriétaire	Résiduel
R1	Injection de prompt indirecte via des docs récupérés	Moy	Élevé	Traitement du contenu non fiable ; moindre privilège ; validation de sortie	Sec eng	Faible
R2	Fuite de données cross-tenant dans un index partagé	Faible	Élevé	Filtre `tenant_id`/ACL au moment de la récupération ; cache cadencé par tenant	Platform	Faible
R3	Un agent sur-privilégié exécute un outil destructeur	Moy	Élevé	Supprimer les outils (moindre privilège) ; hook de permission ; point de contrôle humain	Arch	Faible
R4	PHI mal gérées	Faible	Élevé	BAA ; minimum nécessaire ; logs d’audit ; posture ZDR	Compliance	Faible
R5	Une dépréciation de modèle casse un service épinglé	Moy	Moy	Inventaire de modèles ; suite de régression ; migration canary	Arch	Faible
R6	Une métrique agrégée masque une défaillance de segment	Élevée	Moy	Évals par segment + gate de régression	ML	Faible
R7	Boucle d’agent emballée / pic de coût	Moy	Moy	Contrôle par `stop_reason` + filet d’itérations ; alertes de coût	SRE	Faible

Le risque résiduel est communiqué, non caché

Le rôle du registre est de rendre le risque résiduel explicite pour la conformité et les sponsors (via l’artefact registre des risques, D6). Une conception qui prétend que le risque est nul après atténuation n’est pas crédible.

5.12 Scénario détaillé : un assistant d’admission en santé réglementé

Scénario. Un groupe hospitalier veut un assistant Claude qui lit les formulaires d’admission patient (PHI), suggère une catégorie de triage, et rédige une note pour le clinicien. Basé en UE (GDPR + obligations équivalentes HIPAA applicables via leur branche américaine), sur AWS. Un fournisseur propose Fable 5.1 « pour le meilleur raisonnement », l’auto-triage sans validation du clinicien « pour gagner du temps », une seule règle du system prompt « ne jamais exposer les PHI », et une rétention indéfinie « pour la qualité ».

Trace de raisonnement d’expert.

La rétention/le modèle d’abord. Les PHI plus une posture réglementée imposent typiquement le ZDR ou une rétention stricte — ce qui disqualifie Fable 5.1 (rétention 30 jours). Choisissez Sonnet 5 / Opus 5 avec une posture éligible au ZDR.
Placement. Résidence UE + AWS existant → Bedrock en région UE ; signez un BAA pour les PHI.
Point de contrôle humain. Un triage qui affecte les soins est conséquent → le clinicien conserve l’autorité ; l’auto-triage sans validation est rejeté.
Les PHI ne sont pas protégées par un prompt. « Ne jamais exposer les PHI » en prose est du prompt comme mécanisme d’application. Appliquez avec un accès au minimum nécessaire, la validation de sortie, la journalisation d’audit, et des ACL au moment de la récupération.
Rétention. La rétention indéfinie viole la minimisation GDPR ; fixez des limites de rétention et un chemin DSAR/effacement. Menez une DPIA au design-gate.
Garde-fous en couches + registre. Filtre PII d’entrée → orientation prompt → hooks d’outil → validation de sortie → revue du clinicien ; consignez des risques de type R1–R7 avec propriétaires et risque résiduel.

Pourquoi les alternatives tentantes sont fausses : Fable 5.1 échoue à l’exigence ZDR/rétention ; l’auto-triage supprime le point de contrôle humain obligatoire ; une règle de prompt ne peut pas garantir la protection des PHI ; la rétention indéfinie enfreint la minimisation GDPR et le droit à l’effacement.

5.13 Common misconceptions

Idée reçue	Réalité	Pourquoi c’est important à l’examen
« Un prompt fort applique une règle de sûreté/métier. »	Les prompts sont de l’orientation de couche 2 ; les règles fermes nécessitent hooks/validation.	Le prompt comme mécanisme d’application est la mauvaise réponse n° 1 de D5.
« Le ZDR est disponible sur tout modèle. »	Fable 5.1 nécessite une rétention 30 jours et n’est pas éligible au ZDR.	Les énoncés à ZDR imposé disqualifient Fable 5.1.
« L’API directe peut servir FedRAMP High. »	FedRAMP High passe par les périmètres Bedrock/Vertex.	Les énoncés fédéraux requièrent le périmètre cloud.
« Les outils internes n’ont pas besoin de conformité. »	Les obligations PHI/PII s’appliquent quel que soit l’usage interne.	« C’est interne » n’est jamais une exemption.
« Escaladez quand l’utilisateur semble contrarié. »	Sentiment ≠ complexité/risque ; escaladez sur des signaux mesurés.	L’escalade sur sentiment est l’anti-patron n° 5.
« La sortie d’outil est fiable parce que c’est un outil. »	Le contenu récupéré peut porter une injection indirecte ; traitez comme non fiable.	Les énoncés d’injection indirecte testent ceci.
« Un seul garde-fou fort suffit. »	La défense en profondeur empile des couches indépendantes.	Les réponses à couche unique sont fausses.
« L’automatisation totale supprime le biais humain. »	Elle blanchit le biais et supprime la responsabilité ; gardez l’autorité humaine sur les décisions conséquentes.	Les énoncés recrutement/crédit/clinique requièrent un humain.

Pièges de l’examen dans ce domaine

Piège	Pourquoi c’est faux
Appliquer une règle ferme via le system prompt seulement	Le prompt est de l’orientation (couche 2), non de l’application ; utilisez hooks/validation
Escalader vers un humain en fonction du sentiment	Sentiment ≠ complexité (anti-patron n° 5)
Escalader en fonction de la confiance auto-déclarée	L’auto-déclaration n’est pas fiable (anti-patron n° 4)
Utiliser l’API directe pour une charge FedRAMP High	Utilisez Bedrock/Vertex dans le périmètre FedRAMP
Utiliser Fable 5.1 là où le ZDR est requis	Fable 5.1 nécessite une rétention 30 jours ; disqualifié
Faire confiance à des instructions intégrées dans un document/résultat d’outil	Injection de prompt indirecte ; traitez le contenu externe comme non fiable
Traiter des données personnelles UE sans DPIA / résidence UE	Violation GDPR ; DPIA + résidence + chemin de suppression requis
Traiter des PHI sans BAA	Violation HIPAA ; signez un BAA et appliquez les contrôles PHI
Mettre des secrets dans le prompt ou CLAUDE.md	Risque d’exfiltration ; utilisez des gestionnaires de secrets
Garde-fou à couche unique	Pas de défense en profondeur ; un contournement = échec complet
Sauter la revue humaine pour des actions irréversibles/réglementées	Point de contrôle obligatoire ; la confiance ne le supprime pas
Aucun runbook d’incident / chemin de rollback	Impossible de contenir ou de récupérer en toute sécurité
Satisfaire une réglementation avec une règle de prompt ou un choix de commodité	Les réglementations exigent des contrôles techniques précis, non de la prose
Traiter le risque résiduel comme nul après atténuation	Le risque résiduel doit être communiqué dans le registre des risques
Auto-exécuter des décisions conséquentes sur les personnes (recrutement/crédit/clinique)	Requiert autorité humaine et évaluation d’équité
Manquer le délai de notification de violation GDPR dans le runbook	La notification à 72 heures est une obligation légale
Appliquer les ACL uniquement dans le prompt plutôt qu’au moment de la récupération	Le modèle peut contourner la prose ; appliquez à la couche de données

Questions d’entraînement

Q1 · Un agent financier ne doit jamais déplacer plus de 10 000 $ sans approbation. L’équipe prévoit d’ajouter « ne jamais dépasser 10 000 $ sans approbation » au system prompt. Quelle est la bonne conception ? (Sélectionnez une réponse)

A. La phrase du prompt suffit. B. Appliquer la limite avec un hook de permission d’outil / une validation qui bloque tout transfert supérieur à 10 000 $ et le route vers un point de contrôle d’approbation humaine ; la règle de prompt seule n’est pas de l’application. C. Demander au modèle de reporter sa confiance avant les transferts. D. Escalader seulement quand l’utilisateur semble anxieux.

Réponse : B. Les limites financières fermes exigent une application déterministe (hook + point de contrôle humain). Le prompt n’est que de l’orientation (A, anti-patron n° 3). La confiance auto-déclarée (C, n° 4) et l’escalade sur sentiment (D, n° 5) sont toutes des anti-patrons.

Q2 · Une agence fédérale américaine exige FedRAMP High. Quel déploiement est conforme ? (Sélectionnez une réponse)

A. L’API directe Anthropic pour les modèles les plus récents. B. Claude via Amazon Bedrock ou Google Vertex AI dans le périmètre FedRAMP High. C. N’importe quel cloud, puisque Claude est intrinsèquement conforme. D. Sur un ordinateur portable personnel.

Réponse : B. L’autorisation FedRAMP High est fournie via les périmètres Bedrock/Vertex, non l’API directe. L’API directe (A) n’est pas dans le périmètre FedRAMP ; la conformité n’est pas intrinsèque (C) ; un portable (D) est absurde pour des données fédérales.

Q3 · Une charge réglementée impose le Zero Data Retention. L’équipe veut Fable 5.1 pour son raisonnement. Quelle est la bonne consigne ? (Sélectionnez une réponse)

A. Utiliser Fable 5.1 ; le ZDR s’applique à tous les modèles. B. Fable 5.1 requiert une rétention de 30 jours et n’est pas éligible au ZDR, donc choisir un modèle éligible au ZDR (p. ex. Opus 5 ou Sonnet 5) pour cette charge. C. Désactiver la journalisation pour obtenir le ZDR sur Fable 5.1. D. Utiliser Fable 5.1 mais supprimer les logs après 30 jours.

Réponse : B. Fable 5.1 impose une rétention de 30 jours et ne peut pas satisfaire une exigence ZDR ; un modèle éligible au ZDR est requis. Le ZDR n’est pas universel (A) ; désactiver votre propre journalisation (C) ne change pas la rétention du fournisseur ; la suppression à 30 jours (D) est exactement ce que le ZDR interdit.

Q4 · Un agent résume des pages web, et une page contient un texte caché lui ordonnant d’envoyer par e-mail des données internes vers une adresse externe. Qu’est-ce que c’est, et la bonne défense ? (Sélectionnez deux réponses)

A. Une injection de prompt indirecte. B. Traiter le contenu externe comme non fiable ; appliquer le moindre privilège pour que l’agent n’ait pas d’outil d’e-mail/d’exfiltration sans restriction, et valider/refuser de telles actions. C. Lui faire confiance parce qu’il est arrivé via un outil légitime. D. Augmenter le niveau d’effort du modèle. E. Ajouter l’instruction au system prompt.

Réponse : A et B. Les instructions malveillantes dans le contenu récupéré sont une injection de prompt indirecte ; la défense est le traitement du contenu non fiable plus le moindre privilège et la validation de sortie/d’action. Faire confiance à la sortie d’outil (C) est la vulnérabilité ; l’effort (D) est sans rapport ; l’ajouter au prompt (E) exécute l’attaque.

Q5 · Un hôpital veut un assistant Claude qui lit les dossiers patients. Quelles sont les PREMIÈRES exigences de conformité ? (Sélectionnez deux réponses)

A. Un BAA signé avec le fournisseur de modèle. B. Des contrôles de traitement des PHI (minimum nécessaire, contrôles d’accès, logs d’audit) et une posture rétention/ZDR appropriée. C. Rien, puisque c’est interne. D. Publier les données patients pour améliorer le modèle. E. Escalader sur le sentiment du patient.

Réponse : A et B. Les PHI sous HIPAA requièrent un BAA et des contrôles de traitement des PHI avec audit et discipline de rétention. « Interne » (C) n’exempte pas les PHI ; publier les données patients (D) est une violation ; l’escalade sur sentiment (E) est un anti-patron sans rapport avec la conformité.

Q6 · Un système de support escalade vers un humain chaque fois que le client « semble en colère ». Pourquoi est-ce défaillant ? (Sélectionnez une réponse)

A. C’est optimal. B. Le sentiment n’est pas un proxy de la complexité ou du risque ; l’escalade devrait reposer sur des signaux de complexité/risque mesurés ou des règles déterministes, non l’émotion. C. Il escalade trop rarement. D. La colère signifie toujours que le modèle a échoué.

Réponse : B. L’escalade sur sentiment (anti-patron n° 5) confond l’émotion avec la difficulté de la tâche ; un client calme peut avoir un cas complexe à fort risque et inversement. Ce n’est pas optimal (A) ; la fréquence (C) n’est pas le défaut central ; la colère n’implique pas un échec du modèle (D).

Q7 · Quel ensemble représente le mieux des garde-fous en couches (défense en profondeur) ? (Sélectionnez une réponse)

A. Un seul system prompt très détaillé. B. Classifieur d’entrée → orientation par system prompt → hooks de permission d’outil → validation de sortie → revue humaine pour les actions à fort enjeu. C. Seulement une revue humaine à la fin. D. Seulement une regex de sortie.

Réponse : B. La défense en profondeur empile des couches indépendantes pour qu’un contournement de l’une soit rattrapé par la suivante. Un seul prompt (A), la revue seule (C) ou la regex seule (D) sont des points uniques de défaillance.

Q8 · Pour traiter des données personnelles de résidents UE avec un profil à haut risque, que doit-il se passer avant le lancement ? (Sélectionnez deux réponses)

A. Une DPIA (analyse d’impact relative à la protection des données). B. La résidence des données en UE (p. ex. région Vertex/Bedrock UE) et un chemin de suppression/effacement pour la personne concernée. C. Rien jusqu’à ce qu’une plainte arrive. D. Stocker toutes les données indéfiniment pour la qualité. E. Escalader en fonction de la confiance du modèle.

Réponse : A et B. Le traitement à haut risque de données personnelles UE requiert une DPIA et la résidence plus le support DSAR/effacement sous GDPR. Attendre les plaintes (C) et le stockage indéfini (D) violent le GDPR ; l’escalade sur confiance (E) est un anti-patron sans rapport.

Q9 · Un incident d’injection de prompt est détecté en production. Quel est un premier pas de confinement solide ? (Sélectionnez une réponse)

A. Supprimer tous les logs. B. Faire un rollback vers la version prompt/modèle précédente et/ou désactiver l’outil fautif via son hook de permission, en utilisant les IDs de corrélation et les traces pour délimiter l’impact. C. L’ignorer jusqu’à la prochaine release. D. Divulguer publiquement les données clients pour être transparent.

Réponse : B. Le confinement signifie un rollback rapide et la désactivation de la capacité exploitée, délimités via les traces/IDs de corrélation. Supprimer les logs (A) détruit les preuves ; l’ignorer (C) prolonge le préjudice ; divulguer les données clients (D) cause une seconde violation.

Q10 · Pourquoi faire du red-teaming sur un système Claude avant le lancement ? (Sélectionnez une réponse)

A. Pour satisfaire le marketing. B. Pour trouver proactivement les faiblesses d’injection de prompt, de jailbreak, d’exfiltration et d’agence excessive et réinjecter les correctifs dans les garde-fous et la suite de régression avant que les adversaires ne les exploitent. C. Parce que le red-teaming remplace les évals. D. Parce qu’il garantit un risque nul.

Réponse : B. Le red-teaming fait remonter les vulnérabilités pour qu’elles soient fermées et transformées en tests de régression. Ce n’est pas du marketing (A), ne remplace pas les évals fonctionnelles (C), et ne peut pas garantir un risque nul (D).

Q11 · Où les secrets (clés API, identifiants de BDD) doivent-ils résider pour un agent Claude ? (Sélectionnez une réponse)

A. Dans le system prompt pour que le modèle puisse les utiliser. B. Dans des variables d’environnement ou un gestionnaire de secrets, jamais dans les prompts, CLAUDE.md, ou les logs. C. Dans le fichier CLAUDE.md pour la commodité. D. Codés en dur dans la source de l’outil et imprimés dans les logs.

Réponse : B. Les secrets appartiennent aux env/gestionnaires de secrets et ne doivent jamais entrer dans les prompts, les fichiers de config que le modèle lit, ou les logs. Les mettre dans le prompt (A), CLAUDE.md (C), ou les logs (D) crée des chemins d’exfiltration.

Q12 · Un assistant de présélection de recrutement fait des recommandations conséquentes. Quels contrôles de gouvernance sont REQUIS ? (Sélectionnez deux réponses)

A. Une évaluation d’équité par groupe et un traitement symétrique, revus pour le biais. B. Un décideur humain conserve l’autorité sur la décision de recrutement (supervision humaine pour une décision conséquente et réglementée). C. Automatiser entièrement les décisions pour supprimer le biais humain. D. Escalader seulement quand un candidat semble confiant. E. Stocker toutes les données de candidats indéfiniment.

Réponse : A et B. Les décisions conséquentes sur les personnes requièrent une évaluation d’équité et l’autorité humaine sur le résultat. L’automatisation totale (C) blanchit le biais et supprime la responsabilité ; l’escalade sur sentiment (D) et la rétention indéfinie (E) sont des anti-patrons/problèmes GDPR.

Q13 · Un assistant d’admission en santé traite des PHI, est basé en UE sur AWS, et un fournisseur propose Fable 5.1 avec rétention indéfinie. Quelles DEUX corrections sont REQUISES d’abord ? (Sélectionnez deux réponses)

A. Choisir un modèle éligible au ZDR (Opus 5 / Sonnet 5) car la rétention 30 jours de Fable 5.1 échoue à une posture ZDR/PHI. B. Déployer sur Bedrock en région UE et signer un BAA, avec des limites de rétention et un chemin DSAR/effacement. C. Garder Fable 5.1 mais promettre de supprimer les logs après 30 jours. D. S’appuyer sur une règle du system prompt « ne jamais exposer les PHI ». E. Retenir toutes les données indéfiniment pour la qualité.

Réponse : A et B. Une posture PHI/ZDR disqualifie Fable 5.1 et requiert la résidence UE, un BAA, des limites de rétention et l’effacement. La suppression à 30 jours (C) est exactement ce que le ZDR interdit ; une règle de prompt (D) ne peut pas protéger les PHI ; la rétention indéfinie (E) enfreint la minimisation GDPR.

Q14 · Un architecte doit communiquer le risque résiduel (après atténuation) à une partie prenante de conformité. Quel artefact et quel contenu sont corrects ? (Sélectionnez une réponse)

A. Un ADR listant uniquement la décision technique. B. Un registre des risques cotant chaque risque par vraisemblance × impact avec propriétaire, couche d’atténuation, et le risque résiduel restant. C. Un modèle de coût montrant l’économie unitaire. D. Un diagramme de code C4.

Réponse : B. Un registre des risques avec vraisemblance/impact, propriétaires, atténuations et risque résiduel est l’artefact face à la conformité. Un ADR (A) consigne une décision technique ; un modèle de coût (C) est de l’économie ; un diagramme de code (D) est pour les ingénieurs.

Q15 · Un énoncé indique « traitement à haut risque de données personnelles de résidents UE ». Quel contrôle appartient au DESIGN gate ? (Sélectionnez une réponse)

A. Attendre une plainte avant d’évaluer. B. Réaliser une DPIA et décider de la résidence/du placement UE pour que résidence, rétention et effacement façonnent l’architecture avant le build. C. Ajouter une clause de non-responsabilité à l’UI au lancement. D. Tout stocker pour être sûr.

Réponse : B. Le traitement à haut risque GDPR requiert une DPIA et les décisions de résidence/effacement au design-gate. Attendre (A) est trop tardif ; une clause dans l’UI (C) ne satisfait pas la DPIA ; la sur-rétention (D) enfreint la minimisation.

Q16 · Une agence fédérale américaine impose FedRAMP High et veut le modèle le plus récent le jour de sa sortie. Quelle est la bonne consigne ? (Sélectionnez une réponse)

A. Utiliser l’API directe Anthropic pour l’accès le plus précoce. B. Déployer Claude via Bedrock ou Vertex dans le périmètre FedRAMP High ; l’exigence de résidence/autorisation prime sur le désir d’accès dès le premier jour. C. N’importe quel cloud fonctionne ; Claude est intrinsèquement autorisé. D. L’exécuter sur un portable au bureau.

Réponse : B. FedRAMP High est fourni via le périmètre Bedrock/Vertex, et l’exigence de conformité est contraignante face à la nouveauté. L’API directe (A) est hors périmètre ; l’autorisation n’est pas intrinsèque (C) ; un portable (D) est inacceptable pour des données fédérales.

Q17 · Un runbook de réponse aux incidents pour un système de données personnelles UE manque d’un élément légalement requis. Lequel ? (Sélectionnez une réponse)

A. Une déclaration marketing. B. L’étape de notification de violation GDPR et le délai de 72 heures vers l’autorité de contrôle. C. Une liste des dashboards favoris seulement. D. Une projection de coût.

Réponse : B. Le GDPR requiert la notification de violation (généralement sous 72 heures), donc le runbook doit l’inclure. Le marketing (A), une liste de dashboards (C), et une projection de coût (D) ne sont pas l’exigence légale.

Q18 · Quelle paire cartographie le mieux les mots-signaux vers le bon contrôle d’architecture ? (Sélectionnez deux réponses)

A. « FedRAMP High » → déployer via Bedrock/Vertex dans le périmètre autorisé. B. « ZDR imposé » → ne pas utiliser Fable 5.1 (rétention 30 jours) ; utiliser un modèle éligible au ZDR. C. « PHI » → un system prompt fortement formulé suffit. D. « effacement UE » → retenir les données indéfiniment. E. « IA à haut risque » → sauter la documentation.

Réponse : A et B. FedRAMP se cartographie au périmètre cloud et un ZDR imposé disqualifie Fable 5.1. Les PHI nécessitent un BAA et des contrôles, non un prompt (C) ; l’effacement UE requiert un chemin de suppression, non une rétention indéfinie (D) ; l’IA à haut risque (EU AI Act) requiert de la documentation, non de la sauter (E).

À retenir

Les garde-fous sont en couches : classifieur d’entrée → orientation prompt → hooks de permission d’outil → validation de sortie → revue humaine. Le prompt est de l’orientation, jamais de l’application ferme.
Connaissez la taxonomie des défaillances ; traitez le contenu externe (résultats d’outils, documents, web) comme non fiable pour contrer l’injection de prompt indirecte.
Placez des points de contrôle humains sur les actions irréversibles/réglementées ; escaladez sur la complexité/le risque, jamais le sentiment ni la confiance auto-déclarée.
Accordez le traitement à la réglementation : GDPR (DPIA, résidence, effacement), HIPAA (BAA, PHI), FedRAMP High (Bedrock/Vertex), SOC 2, paliers de risque EU AI Act.
Fable 5.1 requiert une rétention de 30 jours et n’est pas éligible au ZDR — disqualifié là où le ZDR est imposé.
Pratiquez l’IA éthique : évals d’équité, transparence, divulgation, autorité humaine sur les décisions conséquentes.
Menez la gestion du risque modèle, un runbook de réponse aux incidents avec rollback, et le red-teaming alimentant la suite de régression ; gardez les secrets hors des prompts, de CLAUDE.md et des logs.
Cartographiez les mots-signaux vers les contrôles : FedRAMP → périmètre Bedrock/Vertex ; PHI → BAA + contrôles ; effacement UE/haut risque → DPIA + résidence + suppression ; ZDR → pas Fable 5.1.
Tenez un registre des risques (vraisemblance × impact, propriétaire, couche d’atténuation, résiduel) et communiquez le risque résiduel — ne prétendez jamais un risque nul.
Placez les contrôles de conformité à la bonne étape du cycle de vie : DPIA/BAA/palier-de-risque au design, ACL/PII/audit au build, rétention/point-de-contrôle-humain au runtime, notification de violation (72 h) en ops.