IA responsable, sécurité et risque pour les architectes — Claude Certified Architect Professional Prep Course

Écran 1 : La pile de sécurité : qui possède chaque couche et que se passe-t-il en cas de défaillance

ORIENTATION MODULE 2 MIN La pile de sécurité : qui possède chaque couche et que se passe-t-il en cas de défaillance

Les modules précédents se sont terminés par un système de production opérationnel : chaque étape d'un problème partenaire a été assignée au bon propriétaire, une architecture de référence et un modèle ont été choisis, le cas d'usage a été dimensionné, les évals ont été construites comme critères d'acceptation, et les couches d'intégration ont été mises en place pour intégrer Claude dans une pile d'entreprise.

Ce module aborde la question majeure de la sécurité : quels contrôles sont en place pour empêcher un système de refuser une demande valide, de produire un résultat injuste ou de prendre une action que personne n'a approuvée ? La sécurité est un ensemble complet de contrôles, chacun couvrant une partie différente du chemin de la demande, chacun avec un point aveugle que le suivant doit attraper. L'architecte est responsable du placement de chaque contrôle et de la décision de ce qu'il faut faire en cas de défaillance.

À la fin de ce module, vous serez capable de : 1 Distinguer ce que l'entraînement du modèle réduit de ce que votre couche application doit encore appliquer. 2 Placer le filtrage des entrées, le filtrage des sorties et l'autorisation des appels d'outils aux points appropriés du chemin de la demande et déterminer quand utiliser des vérifications basées sur le modèle par rapport aux vérifications déterministes, afin que le système échoue fermé au lieu d'échouer ouvert. 3 Identifier où les résultats inégaux peuvent survenir dans un système et définir les explications requises pour les utilisateurs, les régulateurs et votre propre équipe de débogage, afin que l'équité et la transparence soient intégrées à la conception. 4 Acheminer les décisions vers l'examinateur/décideur approprié en fonction de la confiance, de la réversibilité et du coût d'une mauvaise réponse, afin que l'effort d'examen soit concentré sur les décisions qui le justifient. 5 Mapper chaque obligation de conformité à un contrôle nommé, un propriétaire et un artefact de preuve, afin que l'architecture puisse être auditée avec précision.

Ce module s'adresse à l'architecte qui a déjà construit un système fonctionnel : propriété assignée, architecture choisie, évals construites et Claude intégré dans une pile d'entreprise. Claude arrive avec un large comportement de sécurité en place, mais il ne connaît pas les règles de gestion des données du partenaire, son modèle d'autorisation ou sa politique de domaine. Supposer que Claude applique une règle qu'on ne lui a jamais donnée est la façon la plus courante dont une conception de sécurité peut échouer.

Tout dans ce module est construit autour d'un contexte : un système qui passe chaque examen d'architecture et échoue quand même en production. La couche de responsabilité était incomplète, supposée, ou correcte au moment de la conception mais fausse au moment où quelqu'un l'a auditée. Les partenaires sont des acheteurs d'entreprise dans des environnements réglementés, où un contrôle qui semble solide dans une démo devient une constatation d'audit quand les configurations dérivent ou qu'un examinateur demande une preuve que le contrôle fonctionne.

LES DÉCISIONS CORRESPONDENT AUX SECTIONS QUI SUIVENT

La limite d'alignement est l'endroit où vous tracez la ligne entre ce que l'entraînement du modèle réduit déjà et ce que votre couche application doit encore appliquer. Supposer que l'alignement entraîné couvre une politique de domaine laisse la règle non appliquée dans chaque couche. Le module commence ici car cela impacte chaque décision ultérieure.

Le placement des garde-fous est l'endroit où vous positionnez le filtrage des entrées, le filtrage des sorties et l'autorisation des appels d'outils sur le chemin de la demande, choisissez si chaque vérification est basée sur le modèle ou déterministe, et décidez ce que le contrôle fait en cas de défaillance. Un seul filtre à la fin du chemin ne couvre pas les deux autres points, et un contrôle qui échoue ouvert est pire que pas de contrôle, car il donne l'apparence de protection sans aucune fonction.

L'équité et la transparence est l'endroit où vous identifiez où les résultats inégaux peuvent entrer dans le système, et où vous construisez la journalisation qui vous permet d'expliquer toute décision après coup. Les quatre points d'injection sont les vôtres à instrumenter.

L'acheminement de l'examen humain est l'endroit où vous décidez quelles décisions une personne devrait peser et ce que cet examinateur doit faire pour accomplir son travail. Acheminer simplement par volume inonde la file d'attente et force souvent les examens à s'effondrer en approbations. Les décisions qui justifient l'attention sont celles avec des enjeux élevés et une confiance faible, et ces enjeux doivent être pré-identifiés.

Le registre de contrôle de conformité est l'endroit où chaque obligation devient un contrôle identifié, un propriétaire responsable et un artefact de preuve qu'un examinateur peut inspecter. Choisir un point d'entrée conforme est un prérequis. Un contrôle sans propriétaire et sans artefact vivant peut devenir non opérationnel sans que personne ne le remarque, puis apparaître comme une lacune lors d'un audit.

Ces sujets s'appuient les uns sur les autres. La limite que vous tracez dans la première section est appliquée par les contrôles de la deuxième, la journalisation que vous construisez pour l'équité est la même journalisation que l'examinateur utilise dans la quatrième section, et le registre de contrôle de la cinquième section s'appuie sur chaque couche instrumentée ci-dessus. La tâche cumulative à la fin vous demande d'assembler les cinq dans un déploiement défendable à partir d'un seul brief, ce qui est exactement ce que ce module vous équipe pour faire devant un examinateur de sécurité ou un auditeur de conformité.

CLAUSE DE NON-RESPONSABILITÉ / AVIS POUR CONTENU ÉDUCATIF

Nous avons construit ce cours Architecte Module 3 : IA responsable, sécurité et risque pour les architectes pour vous aider à accomplir un vrai travail avec Claude. Traitez-le comme du contenu éducatif. Il ne constitue pas un conseil juridique, financier ou autre conseil professionnel, alors adaptez ce que vous apprenez à votre situation. Nos produits et services évoluent rapidement, donc certains contenus peuvent contenir des erreurs ou être obsolètes ; n'oubliez pas de vérifier sur le site web ou la documentation d'Anthropic. Les exemples et scénarios utilisés dans le cours sont illustratifs et souvent fictifs. Si le matériel du cours mentionne une entreprise ou un produit, cela ne signifie pas qu'Anthropic les approuve, qu'ils approuvent Anthropic, ou que nous sommes affiliés. Notez également que votre utilisation des produits et services d'Anthropic est couverte par nos conditions, politiques et documentation ; si quelque chose dans ce cours entre en conflit avec eux, ils contrôlent.

Écran 2 : Ce que l'entraînement du modèle applique par rapport à ce que vous possédez

TeachingAlignment11 min Ce que l'entraînement du modèle applique par rapport à ce que vous possédez Le travail antérieur a établi l'architecture, le modèle et l'intégration. Ici, nous répondons : avant de commencer à ajouter des contrôles, combien de comportement sûr est déjà géré par le modèle, et combien est encore le vôtre à construire ? Vous devez comprendre cette limite clairement pour éviter de créer des protections en double ou de supposer que le modèle applique une règle qu'il n'a jamais vue.

Anthropic entraîne Claude selon une constitution : un document écrit qui décrit les valeurs et le comportement que le modèle devrait exhiber, afin que le modèle soit déployé avec un large comportement de sécurité déjà en place. Anthropic révise ce document au fil du temps, et la version publiée la plus récente est de janvier 2026. Le document est utilisé pendant l'entraînement pour générer des exemples que le modèle apprend et pour classer les réponses candidates. Cela façonne la façon dont le modèle répond aux demandes ambiguës ou sensibles mais ne capture pas nécessairement les mauvaises sorties. Il définit un ordre de priorité que le modèle doit suivre quand les objectifs entrent en conflit : être largement sûr, être éthique, se conformer aux directives et être véritablement utile aux opérateurs et aux utilisateurs. Cet ordre est important car une réponse utile est parfois dangereuse. L'ordre est holistique plutôt que strict, donc les objectifs de priorité plus élevée prennent généralement préséance quand ils entrent en conflit, bien que le modèle les pèse ensemble plutôt que de les appliquer dans une séquence rigide. Le modèle arrive avec une classe de sortie nuisible déjà réduite avant que vous n'écriviez un seul prompt. La couche intégrée gère les dommages généraux et à usage général, mais ne couvre pas votre domaine spécifique : toute politique spécifique à vos utilisateurs et produits est encore la vôtre à appliquer.

L'alignement au moment de l'entraînement et le contrôle au moment de l'inférence sont deux couches avec des objectifs distincts L'alignement au moment de l'entraînement façonne le comportement du modèle avant le déploiement. Il réduit les larges classes de sortie nuisible en guidant Claude pour refuser les demandes dangereuses et par défaut vers des réponses plus sûres. Parce qu'il est défini avant tout déploiement, il est général par conception. C'est à la fois une force et une faiblesse : il ne connaît pas la politique de domaine de votre partenaire, ses règles de gestion des données ou son modèle d'autorisation. Une demande peut s'adapter à l'alignement général de Claude et violer quand même une règle spécifique au déploiement, comme divulguer les informations de commande d'un autre client ou conseiller en dehors d'un script approuvé. Rappelez-vous, Claude ne peut pas appliquer une règle qu'on ne lui a jamais donnée. Les règles spécifiques au déploiement sont appliquées par la deuxième couche : le contrôle au moment de l'inférence. Cela inclut les garde-fous d'exécution que vous configurez pour votre déploiement, tels que les instructions système, les vérifications d'entrée et de sortie, les permissions d'outils et les portes d'examen humain. Les instructions système façonnent le comportement du modèle, mais la politique spécifique au déploiement n'est appliquée que quand ces instructions sont associées à des contrôles d'exécution tels que le filtrage, l'autorisation et l'examen. L'alignement au moment de l'entraînement réduit le risque de base, et le contrôle au moment de l'inférence applique les règles spécifiques à votre déploiement.

Une vue en couches : chaque couche a un travail et un point aveugle Traitez la sécurité comme quatre couches empilées de Claude vers l'extérieur. Chacune couvre quelque chose que la couche ci-dessous ne peut pas, et chacune échoue d'une manière que la suivante doit attraper. Sélectionnez chaque couche pour voir ce qu'elle couvre de manière fiable, ce qu'elle ne couvre pas et qui la possède.

Comportement entraîné Instruction du prompt système Filtrage d'exécution Autorisation

Ce qu'elle couvre de manière fiable : Les larges classes de sortie nuisible ou dangereuse, appliquées à chaque demande sans configuration. Ce qu'elle ne couvre pas : Votre politique de domaine, vos règles de données, votre modèle d'autorisation. Qui la possède : Anthropic.

Ce qu'elle couvre de manière fiable : Rôle, ton et contraintes énoncées qui guident Claude dans une demande. Ce qu'elle ne couvre pas : Tout ce qu'une entrée adversariale ou inhabituelle peut faire dire à Claude, puisque les instructions ne sont pas une application. Qui la possède : Architecte.

Ce qu'elle couvre de manière fiable : Filtrage d'entrée et de sortie qui détecte le contenu non autorisé. Ce qu'elle ne couvre pas : Les actions avec effets secondaires, que le filtrage n'autorise pas, et les attaques nouvelles qu'un classificateur manque. Qui la possède : Architecte.

Ce qu'elle couvre de manière fiable : Si une action spécifique avec un effet secondaire est autorisée pour cet appelant dans ce contexte. Ce qu'elle ne couvre pas : La qualité du contenu et l'équité. Qui la possède : Architecte.

Coût · Complexité · Risque Coût : Chaque couche ajoutée coûte en latence et en ingénierie. Un pré-filtrage sur l'entrée et une vérification sur la sortie ajoutent deux appels ou règles supplémentaires à chaque demande. Complexité : Quatre couches signifient quatre endroits à concevoir, versioner et tester. Le prompt système et la logique de filtrage dérivent indépendamment s'ils ne sont pas gouvernés. Risque : La défaillance la plus dangereuse est une défaillance silencieuse : supposer que Claude applique une politique de domaine qu'on ne lui a jamais donnée. Puisque la règle n'existe dans aucune couche, rien ne prévient une violation.

Écran 3 : Quand les refus entraînés sont confondus avec une politique de domaine

Watch OutAlignment3 min Quand les refus entraînés sont confondus avec une politique de domaine

Crochet de configuration Vous êtes un architecte de systèmes fort. Claude refuse déjà largement les demandes nuisibles lors des tests, donc vous supposez que son entraînement couvre également la politique de gestion des données de votre partenaire. Vous continuez sans construire une couche d'application séparée.

Une autopsie : une politique qui n'a jamais été codée dans aucune couche Une équipe a déployé un assistant interne pour un partenaire dont la politique de gestion des données interdisait aux utilisateurs d'accéder aux enregistrements appartenant à d'autres unités commerciales. En examen, Claude avait refusé chaque prompt nuisible que l'équipe lui avait lancé, donc ils ont supposé que la divulgation entre unités était couverte par le même comportement de sécurité et n'ont jamais construit de vérification d'autorisation pour cela. En production, une demande normale et dans le domaine a demandé un enregistrement interdit. Rien dans la demande ne semblait nuisible en termes généraux, donc Claude a répondu. La règle que l'équipe croyait appliquée n'existait en fait pas. Elle n'a jamais fait partie de l'entraînement de Claude, et l'équipe ne l'a jamais codée dans un classificateur, un prompt système ou un contrôle d'application, car elle supposait que le modèle la couvrait déjà.

Pourquoi cela a échoué Une politique de domaine a été confondue avec l'alignement entraîné. Les refus entraînés couvrent les dommages généraux, pas les règles spécifiques au déploiement. Toute règle spécifique à votre partenaire doit être appliquée dans une couche que vous construisez. Rappelez-vous, Claude ne peut pas appliquer ce qu'on ne lui a jamais donné.

Écran 4 : Triez la responsabilité

CheckpointAlignment3 min Triez la responsabilité Essayez maintenant. Vous examinez la conception de sécurité pour un assistant Claude d'un partenaire. Faites glisser chaque obligation dans le compartiment qui devrait l'appliquer : soit le comportement entraîné de Claude, soit la couche application. Le retour explique pourquoi chacun se situe où il se situe.

Refuser d'aider à synthétiser une arme dangereuse Ne jamais retourner les données d'un autre locataire Décliner de produire du contenu clairement haineux Bloquer les conseils en dehors du script approuvé du partenaire Exiger une approbation avant qu'un remboursement ne soit émis

Comportement entraîné de Claude

Couche application (vous la possédez)

Vérifier les réponses Ignorer pour l'instant

Écran 5 : Risques, limitations et modes de défaillance des systèmes LLM

TeachingGuardrails9 min Risques, limitations et modes de défaillance des systèmes LLM Vous avez placé les contrôles ; maintenant identifiez ce qu'ils défendent. Un architecte est censé mener et documenter une évaluation des risques pour un système proposé dans le cadre d'un livrable de sécurité. Cet écran couvre les catégories de risque qui reviennent dans les systèmes LLM et les transforme en une évaluation écrite que vous pouvez exécuter.

Les catégories de risque qui reviennent dans les systèmes LLM La plupart des risques des systèmes LLM se répartissent en un petit ensemble de catégories. Identifiez ces catégories et vérifiez vos conceptions par rapport à chacune :

Injection de prompt directe : Un utilisateur crée une entrée qui remplace les instructions du système et redirige son comportement. Injection de prompt indirecte : Des instructions malveillantes arrivent par le contenu récupéré ou les sorties d'outils que le modèle traite comme fiables et que le filtrage d'entrée vectorielle ne capture pas. Épuisement du budget de tokens : Les entrées surdimensionnées ou remplies de manière adversariale consomment le budget de contexte ou de sortie, tronquant le travail ou gonflant le coût. Abus d'outils et d'actions : Le modèle est induit à appeler un outil avec effet secondaire en dehors de la politique, la défaillance que le contrôle d'autorisation d'action existe pour arrêter. Exposition de données : Les champs sensibles entrent dans la fenêtre de contexte ou les journaux où ils ne devraient pas, créant une fuite indépendante du comportement du modèle.

Évaluation de la vulnérabilité du système : où chercher Parcourez ensemble les chemins de demande et de données. À chaque point d'entrée, entrée utilisateur, contenu récupéré, sorties d'outils, sortie du modèle et journaux, demandez-vous ce qu'un adversaire pourrait faire et quel contrôle se tient en travers. Cherchez n'importe où sans contrôle où il pourrait y avoir une attaque plausible.

Documenter l'évaluation des risques comme un livrable L'évaluation des risques doit être un artefact écrit. Pour chaque risque identifié, enregistrez la catégorie, le composant affecté, un jugement de probabilité et d'impact, et le contrôle d'atténuation avec un propriétaire et un artefact de preuve. Ce document est ce que l'examinateur de sécurité signera, et c'est ce que l'exercice cumulatif à la fin de ce module s'attend à ce que vous puissiez produire.

Écran 6 : Évaluez les risques dans une architecture proposée

CheckpointGuardrails4 min Évaluez les risques dans une architecture proposée Essayez maintenant. Vous examinez une architecture proposée : un agent de support client qui récupère les réponses d'une base de connaissances partenaire et émet des remboursements via un outil connecté, avec toute l'activité écrite dans un journal de demandes. Identifiez au moins trois catégories de risque présentes dans cette conception, et pour chacune nommez une atténuation réalisable. Le risque et une atténuation qui l'adresse sont tous deux requis.

Identifiez les catégories de risque présentes dans cette conception et associez chacune à une atténuation.

Révéler la réponse du modèle Ignorer pour l'instant

Réponse du modèle

Injection de prompt indirecte via la base de connaissances. Le contenu récupéré peut porter des instructions ; l'atténuation consiste à traiter le texte récupéré comme non fiable et à filtrer les entrées d'outils/contenu, pas seulement l'entrée utilisateur.
Abus d'outils et d'actions sur l'outil de remboursement. L'atténuation est une vérification d'autorisation d'action qui s'exécute avant que l'outil de remboursement ne s'exécute, indépendamment de la sortie du modèle.
Épuisement du budget de tokens sur les documents volumineux de la base de connaissances. L'atténuation est le chunking et les limites d'entrée plus la surveillance du budget afin qu'un document volumineux ne puisse pas tronquer le travail silencieusement.
Exposition de données dans le journal de demandes. L'atténuation est la rédaction côté serveur des champs sensibles avant que quoi que ce soit ne soit journalisé.

Écran 7 : Placer le filtrage et l'autorisation afin que le système se dégrade en toute sécurité

TeachingGuardrails14 min Placer le filtrage et l'autorisation afin que le système se dégrade en toute sécurité Un contrôle qui filtre les demandes peut échouer de la même manière que toute dépendance échoue. Il peut expirer, retourner une erreur ou devenir inaccessible sous charge. La différence est qu'un garde-fou défaillant peut quand même sembler sain : quand un service de filtrage génère une erreur mais continue de laisser passer le trafic, les demandes continuent de circuler tandis que le contrôle ne fait aucun du travail pour lequel il a été placé. Donc, quand un garde-fou génère une erreur, le système doit faire l'une de deux choses : le laisser passer ou le bloquer. Si vous n'avez pas fait ce choix explicitement, le code environnant le décide pour vous. La valeur par défaut est presque toujours de laisser la demande passer, ce qui signifie revenir au chemin non protégé. Le même raisonnement qui a mis des retries et des circuit breakers autour de vos appels de modèle s'applique ici : décidez comment le contrôle se comporte en cas de défaillance, plutôt que d'hériter du comportement qui se produit pour maintenir les demandes circulant.

Où les garde-fous se situent dans un chemin de demande Un chemin de demande gardé a quelques points de décision, chacun répondant à une question différente.

Le filtrage des entrées s'exécute avant l'appel du modèle et décide si la demande devrait atteindre le modèle du tout. Le filtrage des sorties s'exécute avant que la réponse n'atteigne l'utilisateur et décide si ce que le modèle a produit est sûr à retourner. L'autorisation des appels d'outils s'exécute avant toute action avec effets secondaires, comme envoyer un email, écrire dans une base de données ou émettre un remboursement, et détermine si cet appelant peut effectuer cette action dans ce contexte.

Parce qu'ils se situent à différents endroits et vérifient différentes choses, un contrôle à un endroit ne fait rien pour les autres, c'est pourquoi un seul filtre ne peut pas couvrir le chemin entier.

Où chaque vérification s'adapte : basée sur le modèle par rapport à déterministe par point de décision Point de décisionUne vérification basée sur le modèle est nécessaire quandUne vérification déterministe est meilleure quand

Filtrage des entrées (avant l'appel du modèle)L'intention est ambiguë et vous attrapez des modèles de jailbreak ou d'injection de prompt qui ne peuvent pas être capturés de manière exhaustive avec des règles. Un modèle léger classifie l'entrée. La règle est claire et définie : une liste de blocage, une regex, une vérification de longueur ou de format. C'est plus rapide, prévisible et ne peut pas être convaincu de sa décision. Filtrage des sorties (avant que la réponse n'atteigne l'utilisateur)Vous évaluez des qualités comme la toxicité ou la conformité à la politique qui nécessitent une compréhension du langage. Un modèle juge note la sortie. Vous vérifiez une chaîne connue, un champ interdit ou une violation de schéma qu'un validateur attrape avec certitude. Autorisation des appels d'outils (avant toute action avec effet secondaire)Rarement. L'autorisation doit être déterministe, afin qu'elle soit auditable. Presque toujours : une liste blanche d'actions autorisées, des vérifications d'identité et une validation de portée. L'autorisation doit être une décision que vous pouvez prouver et rejouer, donc elle doit être déterministe.

Pourquoi les vérifications basées sur le modèle et déterministes échouent différemment, et pourquoi vous les enchaînez Un classificateur basé sur le modèle peut être contourné : un utilisateur peut formuler une entrée d'une manière qui contourne même le plus fort des modèles juges. Une règle déterministe est fragile : elle bloque exactement ce pour quoi elle est programmée pour détecter et rien de plus. Elle manque tout ce qu'elle n'a pas anticipé et sur-bloque tout ce qui ressemble à un modèle restreint. Il n'y a pas de contrôle qui attrape tout, donc ces contrôles sont déployés en série. Identifier ce que chacun manque garantit que chaque lacune est délibérément couverte par un contrôle différent plutôt que laissée ouverte.

Un deuxième vecteur d'injection : les instructions arrivant par le contenu récupéré et les sorties d'outils Le filtrage des entrées utilisateur attrape les instructions que l'utilisateur envoie directement. Il n'attrape pas les instructions intégrées dans le contenu que le système récupère ou reçoit des outils. Dans un système RAG, une instruction malveillante dans un document récupéré atteint le modèle après que le filtrage des entrées a déjà passé la demande. Dans un système d'agent, une réponse d'outil peut porter des instructions que le modèle traite comme faisant autorité. C'est le vecteur d'injection dominant dans les déploiements d'entreprise avec récupération ou utilisation d'outils, et il nécessite un contrôle séparé : filtrer le contenu récupéré et les sorties d'outils avant qu'ils ne soient ajoutés au contexte du modèle, en utilisant le même classificateur basé sur le modèle que vous appliquez à l'entrée utilisateur. Le point aveugle est différent car la source est différente ; identifiez-le explicitement dans votre conception de contrôle pour assurer la couverture.

Sur l'API, les réponses retournent un refus quand les classificateurs de streaming interviennent. L'API Messages le signale comme stop_reason: "refusal" accompagné d'un objet stop_details (disponible depuis Claude Opus 4. 7). Cet objet porte une catégorie de politique ainsi qu'une explication lisible ; les deux champs sont null quand le refus ne correspond pas à une catégorie nommée. L'ensemble de catégories est énuméré dans la documentation des stop-reasons sur platform. claude. com. À ce jour, il inclut cyber, bio, frontier_llm et reasoning_extraction. Revérifiez la liste au moment de la publication plutôt que de la coder en dur. Votre application doit lire la catégorie et acheminer différentes classes de refus en conséquence, plutôt que de traiter chaque refus comme un événement unique et indifférencié. Sur les modèles qui ne retournent pas stop_details, votre gestionnaire doit tolérer un objet absent et revenir à une gestion générique. Vérifiez le support du modèle actuel par rapport à platform. claude. com au moment de la publication. En règle générale, une fois qu'un refus est reçu, réinitialisez le contexte de la conversation avant de continuer : supprimez ou reformulez le tour qui a déclenché le refus, ou effacez l'historique. Envoyer la demande suivante sur le même contexte refusé retourne d'autres refus.

Échouer ouvert par rapport à échouer fermé : comment votre couche de garde-fou se comporte en cas de défaillance Quand le classificateur construit par l'opérateur génère une erreur sous charge, ou que votre service de filtrage construit par l'opérateur est inaccessible, l'application fait l'une de deux choses. Elle peut échouer ouvert et laisser passer le trafic non filtré, ou elle peut échouer fermé et bloquer toute action supplémentaire jusqu'à ce que le contrôle soit sain à nouveau. Le choix vous appartient en tant qu'architecte ; ce sont des composants que votre équipe construit, héberge et configure. Ils sont séparés des contrôles de sécurité du modèle intégrés d'Anthropic, qui ne sont pas configurables par l'opérateur et ne s'ouvrent pas. Un garde-fou construit par l'opérateur qui laisse silencieusement passer le trafic en cas d'erreur est pire qu'un qui bloque le trafic, car il vous donne la certitude d'avoir un contrôle tout en ne fournissant aucune protection. C'est le même raisonnement que le circuit breaker du travail de production : quand une dépendance dans votre pile échoue, dégradez-vous délibérément en fonction de la situation.

Le chemin complet de demande gardée, en tant que système unique Une demande se déplace à travers le chemin dans l'ordre : elle arrive, le filtrage des entrées décide si elle atteint le modèle, le modèle produit une réponse, le filtrage des sorties décide si cette réponse est retournée, et tout appel d'outil que le modèle émet passe par l'autorisation avant qu'il ne s'exécute. Chaque porte peut passer, bloquer ou échouer, et chaque échec se résout dans la direction que vous avez choisie. Chaque porte bloquée ou défaillante est journalisée, afin qu'un incident puisse être reconstruit à partir du dossier.

Le chemin complet de demande gardée Demande utilisateur → Filtrage des entrées (basé sur le modèle pour l'intention ambiguë, déterministe pour les règles définies, défini pour échouer fermé) → Appel du modèle → Filtrage des sorties (modèle juge ou validateur, défini pour échouer fermé) → Autorisation des appels d'outils (liste blanche déterministe plus identité et portée) avant toute action avec effet secondaire → Réponse à l'utilisateur, avec chaque porte bloquée ou défaillante journalisée pour reconstruction ultérieure

Sécurité de la chaîne d'approvisionnement des compétences Vous pouvez entendre l'objection suivante sur le terrain : « Les compétences sont une boîte noire. Je ne peux pas voir tout ce qu'il y a à l'intérieur jusqu'à ce qu'il s'exécute, alors comment suis-je censé lui faire confiance ? » Le travail de l'architecte est de construire un contrôle qui compense cela. Pour rappel, les compétences sont du code réutilisable et distribuable associé à un ensemble d'instructions, regroupés ensemble et déposés dans votre environnement. Ce modèle de distribution est ce qui en fait un risque de chaîne d'approvisionnement. Une compétence non fiable peut porter un exploit d'exécution de code : une logique qui exécute des commandes, atteint le réseau ou touche des fichiers au moment où elle est invoquée. C'est risqué car la compétence peut inclure des instructions malveillantes cachées que vos filtres d'entrée et le filtrage de prompt ne peuvent pas voir ; ceux-ci regardent la conversation, mais la menace a été intégrée au bundle en amont dans la compétence. La surveillance de sortie pourrait attraper un effet en aval après le fait, mais à ce moment-là, le code aura déjà s'exécuté. Donc, la défense doit se déplacer plus tôt dans la chaîne. Avant de pouvoir faire confiance et appeler une compétence, vous devez l'auditer : ouvrez le bundle et lisez-le pour deux choses. Premièrement, cherchez les appels anormaux : demandes réseau, exécution de shell, accès au système de fichiers, lectures d'identifiants. Deuxièmement, les opérations hors de portée : un comportement qui ne correspond pas au travail qu'elle prétend accomplir. Une compétence de formatage qui appelle à la maison est hors de portée ; un résumeur qui écrit sur le disque est hors de portée. L'objectif déclaré d'une compétence devrait être votre ligne de base d'audit, et tout ce qui va au-delà est une constatation que vous devriez enquêter. Votre audit vous dit ce qu'il y a dans votre bundle ; une compétence qui passe l'examen propre peut quand même atteindre pour récupérer du code qui n'a jamais été dans le package que vous avez lu. C'est pourquoi la porte a besoin d'un filet. Exécutez les compétences avec le moins de privilèges et dans un sandbox leur donnant un accès limité aux fichiers, un réseau limité, pas d'identifiants permanents dont elles n'ont pas besoin. L'audit décide ce qui entre ; le confinement d'exécution le contient si l'audit manque quelque chose. Vous devriez utiliser les deux, car aucun contrôle unique ne fonctionnera parfaitement sans l'autre. Vous devriez également considérer d'où les compétences sont autorisées à venir ; ne faites confiance qu'aux compétences d'un registre interne examiné, des éditeurs vérifiés, des versions signées uniquement. Une politique de source fiable réduit la surface que vous devez auditer et arrête les bundles non fiables avant qu'ils n'atteignent l'examen. Une règle de franchise s'applique toujours : ne supposez pas que la plateforme examine les compétences pour vous. Vérifiez ce que l'examen automatisé existe réellement ; lisez la documentation, confirmez la portée de tout balayage, découvrez ce qu'il fait et ne fait pas. Chaque audit doit se terminer par un verdict explicitement enregistré : approuver, rejeter ou remédier. Approuver signifie que c'est propre et autorisé pour utilisation. Rejeter signifie qu'il n'entre pas dans l'environnement. Remédier signifie que vous avez trouvé un problème réparable ; dans ce cas, supprimez l'appel offensant, isolez l'opération, épinglez une version plus sûre, puis ré-auditez-la. Même si vous ne voyez peut-être jamais tout ce qu'une compétence peut faire, le verdict d'audit et une politique de source fiable sont les contrôles compensatoires qui vous permettent d'agir de manière responsable.

Coût · Complexité · Risque Coût : Chaque point de filtrage ajoute un appel ou une évaluation de règle à chaque demande. Un modèle juge sur la sortie double à peu près le coût du modèle pour ce tour. Complexité : Trois points de contrôle, chacun avec un type de vérification, une direction d'échec et une ligne de journal, sont matériellement plus à construire et tester qu'un seul filtre. Risque : Échouer ouvert est l'erreur coûteuse : sous-charger le système laisse silencieusement tomber la protection tout en semblant toujours gardé, donc l'écart ne fait surface que dans un incident. Ce risque ne s'applique pas aux contrôles au niveau de l'API d'Anthropic, qui sont en dehors de votre configuration. Il s'applique exclusivement aux composants que votre équipe construit et exploite.

Écran 8 : Quand un seul filtre de sortie ressemble à une conception terminée

Watch OutGuardrails4 min Quand un seul filtre de sortie ressemble à une conception terminée

Crochet de configuration Le filtrage des sorties est un contrôle clair auquel vous pouvez pointer ; il apparaît comme une boîte propre sur le diagramme d'architecture, il s'active là où un examinateur peut le voir fonctionner, et il se situe à la fin du chemin où le risque semble le plus concret, juste avant que l'utilisateur ne voie une réponse. Donc, si vous ajoutez un classificateur sur la sortie, le diagramme semble complet, et l'examen passe. Le problème est que la chose la plus importante que le système fait peut avoir eu lieu avant que ce classificateur ne s'exécute.

Un extrait de trace où l'outil avec effet secondaire s'est exécuté avant que quoi que ce soit ne vérifie la demande Le modèle a reçu une demande, a appelé un outil qui a émis un remboursement, et l'outil s'est exécuté. Un remboursement est une action financière : l'outil annule une charge et retourne l'argent de l'entreprise au compte du client. Seulement après que l'argent ait bougé, le filtre de sortie a regardé quoi que ce soit. Il a inspecté le texte que le modèle a généré, n'a rien trouvé d'unsafe, et a passé. Le remboursement avait déjà eu lieu. Un contrôle aurait pu se situer à trois endroits sur ce chemin : filtrer la demande en entrée, autoriser l'appel d'outil avant qu'il ne s'exécute, et filtrer la réponse en sortie. Ce système n'avait que le dernier, et il se situait en aval de la seule action sur le chemin qui ne pouvait pas être annulée.

Un agent de service client a accès à un outil issue_refund. Un utilisateur soumet une demande. 1 demande reçue (aucun filtrage des entrées configuré) 2 modèle émet tool_use: issue_refund(order=…) 3 outil s'exécute, remboursement émis (aucune porte d'autorisation avant l'effet secondaire) 4 filtre de sortie inspecte le texte généré (il passe, car l'action qu'il décrivait avait déjà eu lieu)

Pourquoi cela a échoué Un contrôle a été placé à un endroit mais a été traité comme couvrant trois endroits. Le filtrage des sorties juge le texte, pas les actions. Un outil avec effet secondaire a besoin d'une autorisation avant qu'il ne s'exécute, et une entrée non filtrée n'a pas de porte. Un seul filtre à la fin n'est pas un chemin gardé, vous devriez ajouter les trois filtres quand c'est nécessaire.

Écran 9 : Placez les contrôles sur le chemin

CheckpointGuardrails4 min Placez les contrôles sur le chemin Essayez maintenant. Vous recevez quatre contrôles. Chacun répond à deux questions : où il se situe sur le chemin de la demande, et quel type de vérification c'est. Déposez chaque contrôle sur une grille. L'axe horizontal est le point de placement, du filtrage des entrées à l'autorisation d'action avant qu'un outil ne s'exécute, au filtrage des sorties. L'axe vertical est si une vérification déterministe ou basée sur le modèle s'adapte. Le placement correct révèle le raisonnement. Pas chaque zone sera remplie, deux cellules resteront vides.

A. Écran de jailbreak et d'injection de prompt B. Liste de termes bannis sur le message utilisateur C. Juge de toxicité sur la réponse générée D. Vérification de la politique d'autorisation de remboursement avant que l'outil ne s'exécute

Basé sur le modèle Déterministe

Filtrage des entrées

Filtrage des sorties

Autorisation d'action

Vérifier les réponses Ignorer pour l'instant

Écran 10 : Où les résultats inégaux entrent et ce que le système doit expliquer

TeachingFairness11 min Où les résultats inégaux entrent et ce que le système doit expliquer Les contrôles d'exécution empêchent les sorties non autorisées de quitter le système, garantissant que les utilisateurs ne les voient jamais. Cependant, les contrôles d'exécution ne tiennent pas compte d'une sortie qui passe techniquement chaque vérification mais produit des résultats différents pour différentes personnes. Cette défaillance est plus difficile à détecter et plus difficile à attribuer, car, en surface, elle ressemble à une sortie normale.

Les résultats inégaux entrent à des points identifiables L'équité devient plus facile à concevoir une fois que vous arrêtez de la traiter comme un attribut unique du modèle et commencez à la traiter comme quelque chose qui entre à des points spécifiques et identifiables. Dans un système Claude, il y a quatre points d'entrée courants :

Le corpus de récupération peut sur-représenter ou sous-représenter des groupes, donc le contexte que le modèle voit est déjà biaisé. Le cadrage du prompt peut encoder une hypothèse qui pousse les résultats dans une direction. Les exemples utilisés dans le prompting few-shot peuvent porter le même biais que le corpus. Et l'acheminement en aval, ce qui se passe à la sortie du modèle après qu'elle soit produite, peut diriger certains groupes vers des chemins différents.

Chacun de ceux-ci est un point d'injection que vous pouvez inspecter, ce qui rend l'équité une véritable propriété architecturale.

Qui demande détermine ce que le système explique

PublicCe dont ils ont besoinCe que cela vous oblige à capturer

Un utilisateur affectéUne explication claire de pourquoi une décision les affectant a été prise ou exprimée en termes sur lesquels ils peuvent agir. Les entrées qui ont conduit la décision et la raison pour laquelle le résultat a été atteint, sous une forme digeste. Un régulateur Preuve que le système traite les cas comparables de manière cohérente et qu'une décision spécifique peut être reconstruite sur demande. Un dossier durable et interrogeable des entrées, sorties et chemin de décision. Votre équipe de constructionAssez de détails pour trouver pourquoi une décision signalée a mal tourné et la corriger. La trace complète : prompt, contexte récupéré, sortie du modèle et chaque étape d'acheminement, liée à l'observabilité existante.

La journalisation des décisions est ce qui rend ces explications possibles Pour rejouer et expliquer une seule décision, capturez les entrées qui l'ont conduite, le contexte récupéré, la sortie du modèle et l'acheminement qu'elle a suivi. C'est la même instrumentation observable du travail de production, appliquée à une question différente. Cette fois, au lieu de demander si le système est sain, nous demandons pourquoi une décision spécifique s'est produite. L'instrumentation est la même, mais la rétention et le chemin de requête sont différents.

Une liste de contrôle d'équité et de transparence en action Considérez un système d'aide à la décision de crédit. Examinez la liste de contrôle une fois et les critères cessent d'être abstraits :

Lequel des quatre points d'entrée pourrait biaiser ce résultat, et chacun est-il instrumenté ? Pour une décision défavorable, pouvez-vous produire les entrées et la raison en termes sur lesquels le demandeur peut agir ? Si un régulateur demande si des demandeurs similaires ont été traités de manière comparable, pouvez-vous interroger le journal et fournir une réponse ? Votre équipe peut-elle extraire la trace complète pour toute décision signalée ?

Un « non » n'importe où est une lacune de conception.

Discernement : juger les sorties pour un traitement inégal Le discernement est l'une des quatre compétences en fluidité IA : évaluer les sorties et comportements de l'IA. En pratique, cela signifie juger si une sortie de modèle est acceptable, nécessite une révision ou nécessite un remplacement plutôt que de l'accepter. Appliqué à l'équité, le discernement est ce qui permet à un examinateur de reconnaître un résultat biaisé ou injustifié au lieu de seulement confirmer qu'une valeur a été produite. Un dossier de transparence est ce qui rend cette reconnaissance possible en premier lieu.

Coût · Complexité · Risque Coût : Capturer et conserver les journaux au niveau des décisions sur chaque demande ajoute du stockage et un chemin de requête, et le coût augmente avec le trafic plutôt que de rester fixe. Complexité : Instrumenter quatre points d'entrée et servir trois audiences est plus de travail de conception qu'un seul journal d'audit, car chaque audience a besoin d'une tranche différente du même dossier. En plus de cela, la politique de rétention doit maintenant être gouvernée, puisque vous conservez des données au niveau des décisions plus longtemps et pour un objectif spécifique. Risque : La métrique de résultat peut sembler fine globalement tandis que le préjudice est concentré dans un sous-groupe. Un point d'injection non journalisé ou non mesuré peut cacher l'inéquité jusqu'à ce que quelqu'un en dehors de l'équipe la trouve. Gestion des données : Le journal des décisions est lui-même dans le champ d'application du registre de conformité. Dans les contextes HIPAA ou GDPR, les entrées journalisées et le contexte récupéré contiennent des données personnelles sensibles. Appliquez la minimisation, les limites de rétention et les contrôles d'accès au journal, et mappez-le comme un contrôle nommé dans votre registre de conformité. Journaliser tout pour la transparence et épingler les données pour la conformité ne sont pas en conflit, car ils nécessitent le même journal, gouverné différemment.

Écran 11 : Quand l'équité est traitée comme le problème du fournisseur de modèles

Watch OutFairness3 min Quand l'équité est traitée comme le problème du fournisseur de modèles

Crochet de configuration L'équité peut sembler être une propriété du modèle. Le fournisseur de modèles l'a entraîné, a exécuté les évaluations de biais et a publié les résultats, donc il semble raisonnable de traiter l'équité comme quelque chose de géré en amont avant que le modèle n'atteigne votre architecture. Ce cadrage tient jusqu'à ce que votre système associe le modèle à votre propre corpus de récupération, car un corpus qui sur-représente certains cas produit des résultats inégaux que le fournisseur de modèles n'a jamais testés et ne peut pas voir.

Un examen post-incident Ce mode de défaillance vaut la peine d'être reconnu tôt ; l'équipe a fait une hypothèse raisonnable qui s'est avérée être fausse. Ils ont utilisé un modèle qui a passé ses évaluations d'équité, et le biais est entré à un point qu'ils n'avaient pas pensé à surveiller. Ce qui suit est un architecte décrivant la lacune dans un examen post-incident. « Nous avons supposé que l'équité était le travail du modèle. Le biais était dans notre corpus de récupération, et nous avions journalisé si peu que nous ne pouvions pas le prouver. » Les résultats inégaux ne venaient pas de l'entraînement du modèle. Au lieu de cela, ils venaient d'un corpus qui sur-représentait certains cas, un point d'injection que l'équipe n'a jamais surveillé car elle avait assigné l'équité au vendeur. Quand les résultats ont été questionnés, l'équipe avait si peu de journal au niveau des décisions qu'elle ne pouvait pas reconstruire ce qui s'était passé. Ils ne pouvaient ni expliquer les décisions spécifiques que le système avait prises ni exclure le corpus comme cause, ce qui les a laissés incapables de répondre à la seule question que le régulateur posait : d'où venait le biais ?

Pourquoi cela a échoué L'équité a été traitée comme une propriété de modèle que le vendeur possède. Les résultats inégaux entrent à des points que l'architecte contrôle, et le corpus de récupération en est un. Sans journalisation des décisions à ces points, l'équipe ne pouvait pas expliquer le préjudice ou réfuter sa source. L'équité et l'explicabilité sont des exigences d'architecture. Instrumentez-les aux points où le biais peut entrer. Supposer qu'ils arrivent avec le modèle laisse ces points non surveillés.

Écran 12 : Critiquez la conception de la journalisation des décisions

CheckpointFairness3 min Critiquez la conception de la journalisation des décisions Essayez maintenant. Vous regardez un croquis de système pour un flux de support à la décision. Cliquez sur les composants où la transparence est manquante ou insuffisante, comme une étape d'acheminement qui n'est jamais journalisée ou une décision qui ne peut pas être reconstruite. Chaque clic révèle ce que cette lacune signifie pour un utilisateur affecté ou un régulateur. Sélectionnez toutes les lacunes. Laissez les composants adéquatement journalisés non sélectionnés.

✓ LacuneUne étape d'acheminement qui envoie certains cas vers un chemin différent sans entrée de journal.

↓

✓ LacuneUne étape de récupération dont le contexte retourné n'est pas capturé.

↓

✓ LacuneUne sortie de modèle stockée sans les entrées qui l'ont produite.

↓

✓ AdéquatLes entrées, sorties et acheminement sont tous journalisés et liés à un ID de session.

✓ AdéquatLe journal est interrogeable par décision et conservé pendant 90 jours.

✓ LacuneUn tableau de bord de précision agrégée sans ventilation par sous-groupe.

Vérifier les réponses Ignorer pour l'instant

Écran 13 : Acheminer les décisions aux personnes par enjeux, pas par volume

TeachingReview routing10 min Acheminer les décisions aux personnes par enjeux, pas par volume La journalisation des décisions vous a donné un dossier de ce sur quoi chaque décision automatisée était basée : les entrées qu'elle a vues, le chemin qu'elle a pris et la sortie qu'elle a produite. Une décision journalisée peut être expliquée après le fait, mais un journal seul ne décide pas quelles décisions une personne devrait peser avant qu'elles ne prennent effet. Un journal explique les décisions après le fait. Une règle d'acheminement arrête les mauvaises avant qu'elles ne prennent effet du tout. Vous allez déterminer quelles décisions justifient une étape d'examen humain et ce que cet examinateur doit voir à l'écran pour faire l'appel rapidement. Le journal que vous avez déjà construit est la matière première pour cette vue, donc c'est une question de décider ce qu'il faut faire surface et quand, plutôt que d'instrumenter le système à nouveau à partir du début.

Ce qui définit les enjeux d'une décision Pensez à l'examen humain comme un budget : vous avez une quantité finie d'attention des examinateurs, et vous devez la concentrer sur les éléments les plus importants. Les variables suivantes travaillent ensemble pour définir les enjeux d'une décision.

La réversibilité est la facilité avec laquelle une mauvaise décision peut être annulée. Le coût d'une mauvaise décision est ce que l'erreur cause si elle passe sans correction. Ces deux définissent les enjeux de la décision : un choix difficile à annuler et coûteux quand il est faux est à enjeux élevés, indépendamment de la façon dont le système y arrive. La confiance est la troisième variable qui se situe au-dessus des deux autres. C'est le score que le système produit sur sa propre sortie, et c'est utile seulement dans la mesure où il est calibré, car un modèle peut être confidemment faux. La confiance ne change pas les enjeux d'une décision ; elle estime la probabilité que cette sortie soit fausse, ce qui vous dit combien de votre volume devrait être acheminé à une personne pour examen.

Combinez ces variables en une règle : acheminez les décisions à une personne quand elles sont à faible confiance et soit irréversibles soit à coût élevé ; laissez les décisions confiantes, réversibles et à faible coût passer. Une décision confiante, facilement réversible et à faible coût peut généralement s'exécuter sans humain. Une décision à faible confiance, irréversible et à coût élevé a presque toujours besoin d'un examen humain. Les décisions qui consomment votre budget d'examen sont celles où ces variables ne sont pas d'accord. Un cas peut être à coût élevé mais facilement réversible, ou à faible confiance sur quelque chose de trivial à annuler. Quand ils entrent en conflit, donnez plus de poids au coût et à la réversibilité, car ils déterminent les conséquences d'une erreur. Laissez la confiance décider combien de ce volume à enjeux élevés vous pouvez laisser passer sans examen. L'acheminement par confiance porte une hypothèse qui vaut la peine d'être identifiée : le signal de confiance doit être calibré pour que la règle tienne, et confirmer cette calibration est une tâche en soi.

Où le humain se situe est un compromis entre sécurité et vitesse Une fois qu'une décision est acheminée à une personne, vous choisissez où elle se situe dans le flux. Impliquer un humain plus tôt est plus sûr et plus lent.

PlacementCe qu'il vous donnesCe qu'il vous coûte

Approbation pré-actionL'action ne peut pas prendre effet jusqu'à ce qu'une personne l'approuve, donc rien d'irréversible ne se produit sans examen. Cela ajoute de la latence à chaque décision acheminée et une personne doit être disponible, donc cela ne s'adapte pas à un volume élevé. Audit post-actionL'action s'exécute immédiatement et une personne l'examine après, donc le débit reste élevé. Une mauvaise action a déjà pris effet au moment où elle est attrapée, donc cela ne convient que pour les décisions réversibles et à coût inférieur. Examen échantillonnéUne fraction des décisions sont examinées pour surveiller la qualité sans ralentir le processus global. Une mauvaise décision peut glisser sans être échantillonnée, cela surveille le système plutôt que de garder les résultats individuels.

Ce que l'examinateur voit décide si l'examen est exact Un examinateur qui ne peut pas voir pourquoi une décision a atterri dans sa file d'attente peut approuver sans examiner avec le jugement qu'il fallait. Assurez-vous que vos examinateurs ont trois choses : les entrées qui ont conduit la décision, la sortie du modèle et la raison pour laquelle elle a été signalée. Sans cette raison, ils ne peuvent pas faire la différence entre un cas limite et le trafic de routine. Sans les entrées, ils ne peuvent pas dire si la sortie est correcte. Ce que vous mettez devant l'examinateur détermine si l'examen est exact.

La recherche d'Anthropic sur l'autonomie des agents a trouvé que l'exigence d'une approbation sur chaque action ajoute de la friction sans gain de sécurité significatif. Une meilleure approche est d'avoir une personne surveiller ce qui se passe et intervenir quand c'est nécessaire. Un modèle d'Anthropic dans les flux de travail d'agent est de réduire les approbations par étape et de déplacer l'examen vers des points de valeur plus élevée tels que l'examen du plan ou la gestion des exceptions, pour éviter la fatigue de consentement ; la conception d'examen exacte dépend du risque du flux de travail. Sans ce discernement, la fatigue de consentement peut se produire. La fatigue de consentement est quand un système demande une approbation des dizaines de fois de suite, et les examinateurs commencent à cliquer et approuver les éléments sans lire ou fournir la qualité d'examen nécessaire. C'est ce modèle qui a conduit à l'examen au niveau du plan dans Claude Code, où une personne approuve le plan plutôt que chaque étape. Vérifiez le cadrage actuel par rapport à anthropic. com/research/measuring-agent-autonomy et anthropic. com/research/trustworthy-agents au moment de la publication.

Diligence : la compétence derrière l'examen humain La diligence est l'une des quatre compétences en fluidité IA : assurer une collaboration IA responsable. Appliquée au déploiement, cela signifie maintenir des points de contrôle de responsabilité humaine explicites, reconnaître quand la pression d'automatisation érode la surveillance, et auditer les flux de travail pour les lacunes où l'IA agit sans examen, en particulier à mesure que l'automatisation s'adapte. Pour les flux de travail d'agent, la règle d'acheminement devient un modèle de point de contrôle : une porte qui met en pause l'exécution pour examen humain en fonction du risque et de la réversibilité de cette tâche. Placez une porte avant toute action irréversible ou à enjeux élevés qu'un agent prendrait autrement de manière autonome, et échantillonnez les actions à enjeux inférieur au lieu de gater chacune. C'est le même vocabulaire de porte sur lequel la conception multi-agent dépend.

Coût · Complexité · Risque Coût : L'examen pré-action ajoute de la latence à chaque décision acheminée et a besoin de temps d'examinateur, ce qui est un coût d'exploitation récurrent. Complexité : La logique d'acheminement, une interface d'examinateur qui montre les entrées et les raisons de signalisation, et trois chemins de placement sont plus complexes à construire qu'une seule file d'attente d'examen. Risque : L'acheminement par volume plutôt que par enjeux inonde soit les examinateurs et risque une dégradation de la qualité d'examen, soit permet une action à enjeux élevés et irréversible sans porte du tout.

Écran 14 : Quand acheminer tout vers l'examen rend l'examen sans sens

Watch OutReview routing3 min Quand acheminer tout vers l'examen rend l'examen sans sens

Crochet de configuration Décider quelles décisions comptent comme à enjeux élevés prend du jugement, et envoyer tout à l'examen supprime cette étape cruciale. Cela pourrait sembler être la valeur par défaut conservatrice : c'est facile à défendre auprès d'un examinateur de conformité ou d'un auditeur, et cela ne nécessite aucun appel sur où se situent les enjeux. Acheminer tout semble être la réponse sûre précisément parce qu'elle vous épargne de tracer la ligne.

Une courte transcription d'une remise qui a été examinée négligemment La file d'attente d'un examinateur est rarement vue jusqu'à ce qu'elle échoue. Le modèle ci-dessous montre ce qui se passe quand un système achemine chaque sortie à une personne et ne donne à cette personne rien à examiner. Deux choses distinctes vont mal à la fois, et le dialogue fait surface les deux : le volume est plus que quiconque ne peut lire, et chaque élément arrive dépouillé du contexte qui permettrait à l'examinateur de le juger.

Examinateur : Il y a quatre cents éléments dans ma file d'attente aujourd'hui. Pareil qu'hier. Chef : Lisez-vous les entrées sur chacun ? Examinateur : Il n'y a aucun moyen. Je reçois la sortie et un bouton d'approbation, c'est tout. Je ne vois même pas les entrées, ou pourquoi celui-ci a atterri avec moi. Après la première heure, je dois juste cliquer sur approuver pour suivre le rythme.

La conception a envoyé toutes les sorties pour examen et a donné à l'examinateur la sortie seule, sans entrées et sans raison de signalisation. Le volume a rendu l'examen attentif impossible, et le contexte manquant l'a rendu sans objet, donc l'examen s'est effondré en approbation. Une décision à enjeux élevés dans cette file d'attente a reçu la même approbation de routine qu'une triviale.

Pourquoi cela a échoué Deux défaillances indépendantes se sont empilées ici, et l'une seule est suffisante pour causer l'examen à devenir négligent. La première est le volume. Quand le nombre d'éléments acheminés à une personne dépasse ce qu'elle peut lire dans le temps qu'elle a, la surveillance qui couvre tout n'examine rien, car l'examinateur se désintéresse pour suivre le rythme. La correction est la règle d'acheminement : envoyer les décisions à une personne par enjeux, en utilisant la confiance, la réversibilité et le coût, afin que la file d'attente ne contienne que les décisions qui justifient l'attention plutôt que toutes. La deuxième est le contexte manquant. Un examinateur qui voit seulement la sortie et un bouton d'approbation n'a rien pour vérifier la sortie, donc même une file d'attente courte est difficile à juger avec précision. La correction est de décaler ce qui se situe dans la vue de l'examinateur : faire surface les entrées sur lesquelles la décision était basée et la raison pour laquelle l'élément a été signalé, afin que l'examinateur puisse voir ce qu'on lui demande de peser. Si vous ne corrigez qu'une de ces défaillances, c'est quand même possible que l'examen échoue. Une petite file d'attente sans contexte et une vue d'examinateur bien construite noyée sous le volume échouent tous les deux.

Écran 15 : Construisez la règle d'acheminement d'examen

CheckpointReview routing3 min Construisez la règle d'acheminement d'examen Essayez maintenant. Une règle d'acheminement a trois contrôles : un seuil de confiance, le coût d'une mauvaise réponse et un paramètre de réversibilité. L'objectif est d'acheminer les décisions à faible confiance et à enjeux élevés à une personne avant qu'elles ne prennent effet, tout en gardant la file d'attente d'examen sous le plafond de l'examinateur. Choisissez la règle qui répond aux deux objectifs à la fois.

A. Acheminez tout ce qui est en dessous d'un seuil de confiance élevé vers l'examen, indépendamment des enjeux. B. Acheminez les décisions qui sont à faible confiance ET soit irréversibles soit à coût élevé vers l'examen pré-action ; laissez les décisions confiantes, réversibles et à faible coût passer. C. Acheminez par confiance seule, défini assez bas pour garder la file d'attente petite. D. Envoyez chaque décision à l'examen pour être sûr.

Maintenant complétez cette étape : En 1–2 phrases, nommez le contrôle unique décisif, ce qui fait qu'un cas à faible confiance achemine quand même à une personne même quand la confiance est dans la tolérance ?

Révéler la réponse du modèle

Réponse du modèle La réversibilité et le coût d'une mauvaise réponse sont les contrôles décisifs, pas la confiance. La confiance filtre le volume que vous acheminez, mais elle ne change pas les enjeux de la décision. Un cas peut être confiant et quand même acheminer à un humain s'il est assez irréversible ou à coût élevé pour le justifier.

Marquer comme complet

Ignorer pour l'instant

Écran 16 : Transformer chaque obligation de conformité en contrôle avec preuve

TeachingCompliance10 min Transformer chaque obligation de conformité en contrôle avec preuve La couche de conformité du modèle d'intégration a utilisé l'obligation gouvernante comme un pré-filtre : HIPAA, GDPR, FedRAMP, privilège avocat-client ou une politique de résidence des données ont chacun gouverné les routes de livraison et les points d'entrée dedans ou dehors avant que le coût ou la préférence d'ingénierie n'entrent dans la conversation. Ce travail vous amène à un point d'entrée et une route qui survivent à l'obligation, mais l'étape suivante est plus étroite et plus difficile. Chaque obligation survivante doit maintenant devenir un contrôle avec un propriétaire nommé. Un examinateur de sécurité et juridique ne traite pas un point d'entrée conforme seul comme preuve que la règle est respectée. Ils demandent aussi qui possède le contrôle et quelle preuve montre qu'il tient en pratique.

Une régulation énonce un résultat, mais vous fournissez le contrôle et la preuve qu'il fonctionne Les cadres tels que GDPR, HIPAA et FedRAMP énoncent des résultats, pas des implémentations. Ils disent ce qui doit être vrai : que les données protégées doivent être gérées d'une certaine manière, que l'accès doit être contrôlé et que le traitement doit se produire dans un environnement autorisé, mais ils vous laissent le contrôle technique. Chaque obligation devient trois choses que vous possédez : un contrôle technique spécifique qui réalise le résultat, un propriétaire responsable de lui, et un artefact de preuve qui montre qu'il est en direct. Rappelez-vous toujours d'inclure l'artefact de preuve ; c'est ce que l'examinateur vérifiera et c'est le plus souvent manqué.

Mapper les obligations aux contrôles, propriétaires et preuves Mapper les obligations aux contrôles, propriétaires et preuves Obligation (cadre)Contrôle techniqueLa preuve qu'un examinateur acceptePropriétaire

Les données de santé protégées gérées selon un accord (HIPAA)Utilisez uniquement un plan Enterprise prêt pour HIPAA ou une configuration API première partie couverte par un accord d'associé commercial signé, avec la conformité HIPAA activée et seulement les fonctionnalités éligibles dans le champ d'application. L'accord d'associé commercial signé et le paramètre d'administration montrant la conformité HIPAA activée, plus la liste des fonctionnalités éligibles. Chef de la sécurité La charge de travail du gouvernement américain au niveau d'impact requis (FedRAMP)Livrer via une route autorisée documentée par Anthropic qui répond au niveau d'impact requis, pas un point d'entrée non autorisé. Le dossier d'autorisation pour la route choisie et la confirmation que la charge de travail s'exécute exclusivement sur elle. Propriétaire de la plateforme Les données gérées et stockées dans une région approuvée (résidence des données)Configurez le traitement et le stockage régionaux pris en charge pour la région approuvée, et validez si les journaux, caches, surveillance et chemins de rétention restent dans la limite approuvée. La configuration de résidence et un dossier de flux de données montrant où chaque copie vit. Propriétaire des données Les décisions reconstruisables sur demande (transparence, inter-cadre)La journalisation des décisions construite dans le cluster d'équité, conservée et interrogeable pour la période requise. Une reconstruction d'exemple d'une décision du journal en direct. Architecte

Utilisation de l'entraînement par rapport à la rétention, deux affirmations distinctes Ne pas effondrer l'utilisation de l'entraînement et la rétention dans la même affirmation : les données peuvent être exclues de l'entraînement du modèle par défaut tout en étant conservées ou surveillées à des fins de journalisation, de prévention des abus, de conformité juridique ou d'objectifs d'audit configurés.

L'artefact de preuve est ce qui rend la remise efficace Le raisonnement d'élimination des contraintes du travail d'intégration se poursuit ici. À l'époque, vous avez éliminé les routes de livraison qui ne pouvaient pas survivre à une contrainte. Maintenant, vous enregistrez, pour chaque obligation, le contrôle qui la satisfait et l'artefact qui le prouve. Un examinateur de sécurité et juridique accepte la preuve qu'un contrôle est en direct : un accord signé, un écran de configuration, un dossier d'autorisation ou une requête de journal retournée. Ce qu'ils n'acceptent pas est un document de conception qui identifie un contrôle sans propriétaire et sans preuve ; un contrôle que personne ne peut démontrer fonctionne est indiscernable d'un qui ne fonctionne pas.

Coût · Complexité · Risque Coût : Produire et maintenir la preuve pour chaque obligation est un travail continu. Les configurations dérivent et les artefacts deviennent obsolètes, donc le registre est revalidé sur un cadence régulier. Complexité : Un contrôle, un propriétaire et un artefact de preuve vivant par obligation est plus de gouvernance qu'un choix de point d'entrée, et il s'étend sur les propriétaires de sécurité, juridique et plateforme qui doivent chacun être d'accord sur qui tient quoi. Risque : Un contrôle spécifié sans propriétaire et sans preuve est invisible à l'audit. Il peut cesser de fonctionner sans que personne ne soit responsable, et l'écart fait surface en examen plutôt qu'en conception, ce qui est l'endroit le plus coûteux pour le trouver.

Écran 17 : Quand passer la sélection du point d'entrée semble terminer la conformité

Watch OutCompliance3 min Quand passer la sélection du point d'entrée semble terminer la conformité

Crochet de configuration Passer le pré-filtre de contrainte et pouvoir prouver la conformité sont deux choses différentes. Le pré-filtre vous donne un signal clair. Choisir une route de livraison qui survit à HIPAA, GDPR ou FedRAMP produit un résultat immédiat et visible : la route est autorisée, le point d'entrée est autorisé, la conception peut avancer. Prouver que chaque obligation est respectée ne produit rien de visible au moment de la conception, car la preuve est un artefact que vous devez construire, attacher à un propriétaire et garder vivant à mesure que les configurations changent. Cet écart est facile à manquer, car le moment qui semble être une ligne d'arrivée et le moment où un examinateur vérifie sont souvent des mois d'écart.

Un déploiement qui a choisi la bonne route mais ne produit aucune preuve Une équipe a sélectionné une route de livraison conforme pour une charge de travail réglementée et a traité la conformité comme réglée. Ils avaient mappé les obligations aux contrôles une fois, au moment de la conception, dans un document. Aucun propriétaire n'a été attaché aux contrôles, et aucune journalisation n'a été câblée pour montrer qu'un contrôle fonctionnait. L'obligation de résidence des données est l'endroit où la défaillance s'est concentrée. Le contrôle était correct sur papier : traitement épinglé à la région approuvée. Cependant, des mois plus tard, une configuration de journalisation a changé et a commencé à écrire les métadonnées de demande dans un magasin dans une deuxième région. Rien n'a identifié le changement, car personne ne possédait le contrôle de résidence et aucun artefact ne suivait où les données atterrissaient. L'écart a fait surface à l'audit, pas à la conception, quand un examinateur a demandé une preuve que les données restaient dans la région et l'équipe avait un document de conception au lieu d'un dossier de flux de données.

Pourquoi cela a échoué Survivre au pré-filtre a été confondu avec l'établissement de la conformité. Une route conforme est un prérequis, pas une preuve. Chaque obligation a besoin d'un contrôle, d'un propriétaire nommé et d'un artefact de preuve vivant qui est revalidé à mesure que le déploiement change. Le contrôle de résidence dans cette histoire était réel au moment de la conception et silencieusement faux en production, et rien n'a attrapé la différence car aucun artefact ne le surveillait.

Écran 18 : Justifiez le choix du contrôle

CheckpointCompliance3 min Justifiez le choix du contrôle Essayez maintenant. Vous recevez une obligation de conformité pour un déploiement réglementé. Choisissez le contrôle technique qui l'evidencie, puis sélectionnez la raison unique et décisive pour laquelle un examinateur de sécurité et juridique accepterait ce contrôle comme preuve. Vous réussissez seulement quand les deux atterrissent : le contrôle doit s'adapter à l'obligation, et vous devez nommer pourquoi il compte comme preuve qu'un examinateur peut inspecter. Obligation : Les données de santé protégées doivent être gérées selon un accord formel (HIPAA).

A. Un plan prêt pour HIPAA ou une API première partie sous un accord d'associé commercial signé, car l'accord signé plus la configuration activée est l'artefact qu'un examinateur peut inspecter comme preuve. B. Un plan prêt pour HIPAA sous un accord d'associé commercial signé, car le modèle est instruit de gérer les données de santé avec soin. C. Un filtre de contenu basé sur le modèle sur les termes de santé, car il attrape les données sensibles à l'exécution.

Vérifier la réponse Ignorer pour l'instant

Écran 19 : Assemblez un déploiement responsable

CumulativeModule8 min Assemblez un déploiement responsable Essayez maintenant. Vous recevez un brief autonome, et vous prenez cinq décisions séquencées qui construisent un déploiement responsable. Les décisions s'exécutent dans l'ordre car chacune définit les conditions pour la suivante. Un choix faible au début restreint ce que les suivants peuvent faire. Si vous laissez une règle de domaine dans le comportement entraîné à la décision un, il n'y a pas de couche en aval qui peut la remettre.

Vous avez construit chaque couche seule à travers le module. Voici la pile que vous assemblez, dans l'ordre :

Le comportement entraîné façonne la sécurité de base ; votre politique d'application définit les règles spécifiques au domaine ; les contrôles d'exécution ci-dessous appliquent ces règles en opération. Le filtrage et l'autorisation d'exécution se situent sur le chemin de la demande et arrêtent le contenu non autorisé et les actions non autorisées. Les contrôles d'équité et de transparence adressent les résultats inégaux à leur source et assurent que chaque décision peut être reconstruite. Ils dépendent d'une journalisation efficace. L'acheminement d'examen humain envoie les décisions qu'un modèle ne devrait pas finaliser seul à une personne, par enjeux. Il dépend de la même journalisation. Le registre de contrôle lie chaque obligation à un contrôle, un propriétaire et un artefact de preuve.

Le brief Un assistant d'avantages du secteur public aide une agence à déterminer l'admissibilité au programme, recommandant d'approuver, refuser ou renvoyer. Le brief vous donne ce que les décisions ont besoin et rien de plus : Cadre : FedRAMP au niveau d'impact requis par l'agence, plus la règle de l'agence qu'un demandeur refusé obtient la raison spécifique. Cas à enjeux élevés et faible confiance : Un demandeur près du seuil d'admissibilité avec documentation incomplète, où un refus erroné supprime les avantages de quelqu'un. Sortie sujette au biais : La recommandation et la raison attachée à un refus. Données : Champs soumis par le demandeur, dossiers d'agence récupérés au moment de la décision et toute fonctionnalité dérivée.

Définissez la limite entre le comportement entraîné et votre couche application.

Placez les contrôles d'exécution.

Spécifiez les contrôles d'équité et de transparence.

Définissez l'acheminement d'examen humain.

Construisez le registre de contrôle.

Révéler la réponse du modèle Ignorer pour l'instant

Réponse du modèle

Définissez la limite entre le comportement entraîné et votre couche application. Le comportement entraîné refuse les larges classes de dommages mais n'a jamais vu les règles d'admissibilité de ce programme, donc celles-ci appartiennent à la couche application. Les laisser dans le comportement entraîné et aucun contrôle en aval ne peut les atteindre.
Placez les contrôles d'exécution. Positionnez le filtrage des entrées, le filtrage des sorties et l'autorisation des appels d'outils, choisissez basé sur le modèle ou déterministe à chacun, et définissez la direction de défaillance. Échouez fermé, car un écran qui échoue ouvert laisse un refus non filtré atteindre un demandeur.
Spécifiez les contrôles d'équité et de transparence. Nommez lequel des quatre points d'injection (corpus, cadrage du prompt, exemples, acheminement) pourrait biaiser ce résultat, et construisez la journalisation des décisions une fois, puisque le demandeur affecté, le régulateur, l'équipe de construction et le registre de contrôle en tirent tous.
Définissez l'acheminement d'examen humain. Acheminez par confiance, réversibilité et coût d'une mauvaise réponse, et choisissez un placement : approbation pré-action, audit post-action ou examen échantillonné. Envoyez un refus à faible confiance et difficile à annuler vers l'approbation pré-action. Clé la règle sur les enjeux, pas le volume, ou une file d'attente tranquille laisse passer un refus à enjeux élevés.
Construisez le registre de contrôle. Mappez chaque obligation FedRAMP à un contrôle, un propriétaire et l'artefact de preuve qu'un examinateur accepte. Un contrôle sans artefact de preuve est une affirmation que vous ne pouvez pas prouver a fonctionné.

Les réponses fortes sont spécifiques : elles nomment quels points d'injection, nomment la direction de défaillance, nomment les variables de la règle d'acheminement et nomment l'artefact de preuve. Les réponses faibles décrivent le concept général sans l'appliquer à ce déploiement. Vérifiez chaque décision par rapport au brief, les détails du cadre de conformité et du cas à enjeux élevés devraient apparaître dans vos réponses.

Marquer comme complet

Écran 20 : Glossaire

ReferenceWrap-up Glossaire Les termes clés utilisés dans ce module, dans l'ordre alphabétique. Cliquez sur un terme pour développer sa définition.

Accord d'associé commercial (BAA)Un contrat en vertu de HIPAA qui permet à un vendeur de traiter les données de santé protégées au nom d'une entité couverte, définissant les protections et responsabilités de chaque partie. Sans lui, le traitement de ces données via le vendeur n'est pas conforme indépendamment des contrôles techniques. Fatigue de consentementL'effondrement de la surveillance quand un examinateur est invité à approuver trop d'actions, donc il approuve presque tout sans vrai examen. C'est le mode de défaillance de l'acheminement de chaque décision à un humain. Vérifiez le cadrage actuel d'Anthropic par rapport à anthropic. com. ConstitutionLe document écrit qu'Anthropic utilise pendant l'entraînement pour façonner les valeurs et le comportement de Claude, énonçant un ordre de priorité de largement sûr, éthique, conforme aux directives et véritablement utile. Il façonne le comportement entraîné du modèle mais ne code pas la politique de domaine d'un déploiement. Vérifiez la version actuelle par rapport à anthropic. com. Registre de contrôleUne table qui mappe chaque obligation de conformité à son contrôle technique, un propriétaire responsable et un artefact de preuve, afin qu'un déploiement réglementé puisse être audité en tant que registre plutôt qu'affirmé en tant que récit. Résidence des donnéesL'exigence que les données sont traitées et stockées dans une région géographique spécifiée, y compris les copies dans les journaux et les caches. C'est le contrôle derrière de nombreuses obligations de souveraineté des données. Journalisation des décisionsCapture des entrées, du contexte récupéré, de la sortie du modèle et de l'acheminement pour chaque décision, clé afin qu'une décision puisse être rejouée et expliquée plus tard. C'est la même instrumentation d'observabilité pointée sur la question de pourquoi une décision spécifique s'est produite. Artefact de preuvePreuve concrète qu'un examinateur de sécurité et juridique accepte qu'un contrôle est en direct : un accord signé, un écran de configuration, un dossier d'autorisation ou une requête de journal retournée. Un contrôle nommé dans un document de conception sans artefact est une affirmation, pas une preuve. Échouer ouvert par rapport à échouer fermé Comment un garde-fou se comporte quand il génère lui-même une erreur. Échouer ouvert laisse passer le trafic non filtré, tandis qu'échouer fermé bloque jusqu'à ce que le contrôle soit sain. Pour les contrôles de sécurité, échouer fermé est le choix délibéré, car un contrôle qui laisse silencieusement passer le trafic n'offre aucune protection. FedRAMPLa classification FedRAMP (faible, modérée ou élevée) qui définit les contrôles de sécurité qu'un service cloud doit respecter pour gérer les charges de travail du gouvernement américain d'une sensibilité donnée. Le niveau requis est défini par la charge de travail, et la route de livraison doit être autorisée à ou au-dessus de celui-ci. GDPRLa loi sur la protection des données de l'UE concernant la façon dont les organisations collectent, traitent, stockent et transfèrent les données personnelles des personnes dans l'UE et l'EEA. Elle accorde aux individus des droits sur leurs données et exige une base légale pour le traitement, la minimisation des données et la protection. HIPAAA loi fédérale américaine établissant des normes pour la protection des informations de santé des individus. Elle régit la façon dont les informations de santé protégées (PHI) sont utilisées, divulguées et sauvegardées par les entités couvertes et leurs associés commerciaux. Quand un vendeur traite PHI au nom d'une entité couverte, HIPAA exige un accord d'associé commercial (BAA) définissant les protections et responsabilités de chaque partie. Dans ce module, cela conduit à l'exigence de livrer via un plan prêt pour HIPAA ou une API première partie sous un accord d'associé commercial signé. Acheminement humain dans la boucleUne règle qui envoie les décisions à une personne en fonction de la confiance, de la réversibilité et du coût d'une mauvaise réponse, plutôt que par volume, avec l'examinateur placé pré-action, post-action ou dans un échantillon. Point d'injection (équité)Un endroit spécifique où les résultats inégaux peuvent entrer dans un système : le corpus de récupération, le cadrage du prompt, les exemples choisis ou l'acheminement en aval. Les nommer rend l'équité une propriété d'architecture que vous pouvez instrumenter plutôt qu'un attribut de modèle que vous supposez. Filtrage des entréesUne vérification qui s'exécute avant l'appel du modèle pour décider si une demande devrait atteindre le modèle, en utilisant un classificateur basé sur le modèle pour les intentions floues comme les jailbreaks ou un déterministe pour les modèles nets. Modèle jugeUn modèle utilisé pour noter ou classer la sortie d'un autre modèle, pour des qualités comme la toxicité ou la conformité à la politique qu'une règle déterministe ne peut pas encoder de manière fiable. Il peut être contourné, c'est pourquoi il est enchaîné avec des vérifications déterministes. Filtrage des sortiesUne vérification qui s'exécute avant que la réponse n'atteigne l'utilisateur, jugeant le contenu généré avec un modèle pour des qualités comme la toxicité ou un validateur pour les chaînes connues et les violations de schéma. Autorisation des appels d'outilsUne vérification avant toute action avec un effet secondaire qui décide si cet appelant peut effectuer cette action dans ce contexte. Elle doit être déterministe, une liste blanche d'actions autorisées plus identité et portée, afin que la décision soit prouvable et auditable. Alignement au moment de l'entraînement par rapport au contrôle au moment de l'inférenceL'alignement au moment de l'entraînement est le comportement sûr intégré au modèle pour chaque utilisateur. Le contrôle au moment de l'inférence est le filtrage et l'autorisation que vous ajoutez au moment de la demande pour appliquer les règles spécifiques à votre déploiement. Confondre les deux laisse les règles spécifiques au déploiement non appliquées.

Écran 21 : Cinq choses qui tiennent partout ici

RecapModule3 min Cinq choses qui tiennent partout ici

La sécurité est une pile de couches, pas un paramètre L'entraînement réduit les dommages généraux pour chaque demande mais n'a jamais vu la politique de domaine de votre partenaire, ses règles de données ou son modèle d'autorisation, donc tracez la limite explicitement et identifiez ce que chaque couche couvre. La défaillance dangereuse est silencieuse : supposer que Claude applique une règle qui n'existe pas dans une couche.

Un chemin gardé a trois points de contrôle et une direction de défaillance choisie Le filtrage des entrées, le filtrage des sorties et l'autorisation des appels d'outils répondent à des questions différentes, donc un seul filtre à la fin ne couvre pas les deux autres. Laissez les erreurs de contrôle échouer fermé pour les décisions où une mauvaise passe cause du préjudice, car un garde-fou qui laisse silencieusement passer le trafic vous donne l'apparence de protection sans aucune fonction.

L'équité et la transparence sont instrumentées, pas supposées Les résultats inégaux surgissent à des points que vous contrôlez, comme le corpus, le cadrage du prompt, les exemples et l'acheminement, donc traiter l'équité comme la responsabilité du vendeur laisse ces points non surveillés. Journalisez chaque décision afin que les utilisateurs, les régulateurs et votre équipe puissent la reconstruire. Si vous ne pouvez pas reconstruire une explication, vous ne pouvez pas la fournir de manière fiable.

Acheminez l'examen par enjeux, pas par volume La confiance, la réversibilité et le coût d'une mauvaise réponse définissent quelles décisions une personne devrait examiner, donc envoyez les décisions à enjeux élevés et à faible confiance à un humain avec les entrées et la raison de signalisation et laissez le reste passer. Acheminer tout inonde la file d'attente jusqu'à ce que les examinateurs cliquent sans lire.

Un point d'entrée conforme est un prérequis, et un ensemble de contrôles evidencés est la preuve Une régulation énonce un résultat et vous laisse le contrôle, donc transformez chaque obligation en un contrôle spécifique, un propriétaire nommé et un artefact de preuve vivant que vous revalidez au fil du temps. Un contrôle sans propriétaire et sans preuve finit par devenir non opérationnel et échoue à l'audit, car ce qu'un examinateur accepte est la preuve que le contrôle fonctionne, pas le contrôle lui-même.

Ce qui vient ensuite Le module suivant passe de la construction d'un déploiement responsable à sa remise et sa gestion. Vous prendrez l'architecture que vous pouvez maintenant evidencer et communiquerez ses compromis aux parties prenantes non techniques, la documenterez selon une norme et la gérerez à travers le cycle de vie découverte-remise. Le registre de contrôle et la limite en couches que vous avez construits ici deviennent la documentation et la ligne de base sur laquelle repose la remise.

Sources

Building with the Claude API (Skilljar Course 4), utilisé pour les évaluateurs de modèles, la mécanique des appels d'outils, les sorties structurées et le modèle d'évaluateur. platform. claude. com/docs et platform. claude. com, utilisé pour la modération de contenu, le guide des garde-fous, les refus de streaming et les sorties structurées. anthropic. com, utilisé pour la constitution de janvier 2026 et la posture de sécurité actuelle. Centre de confiance d'Anthropic et Centre de confidentialité, utilisé pour la posture HIPAA, FedRAMP et de résidence des données. Storyboards Architect M1 et M2, utilisés pour référencer plutôt que de ré-enseigner l'assignation des propriétaires, les architectures de référence, la stratégie de modèle et de contexte, les évals, les couches d'intégration et l'observabilité.

Vous pouvez concevoir des systèmes IA qui répondent aux exigences de sécurité et de conformité. La conception des contrôles, la collecte de preuves, l'assignation des propriétaires et la préparation à l'audit, un contrôle sans propriétaire et sans preuve échoue quand cela compte le plus.

Écran 22 : Félicitations ! Vous avez terminé ce module avec succès.

Module Complet · Architecte · 2 min Félicitations ! Vous avez terminé ce module avec succès. Le Module 3 couvre les cadres de sécurité, les catégories de risque et les décisions de conception de contrôle que les architectes IA responsables appliquent avant et pendant le déploiement en production. Un chemin gardé n'est pas un filtre à la fin, c'est un contrôle à chaque étape où le préjudice peut entrer.

0 de 0 points de contrôle réussis

Conception de plateforme et de solution Claude Sélection de modèle, architecture de prompt, conception d'outils et compromis au niveau de la plateforme.

Intégration d'entreprise et production Modèles de déploiement, architecture d'intégration et fiabilité en production.

IA responsable, sécurité et risque Cadres de sécurité, identification des risques et pratiques de gouvernance.

Vous êtes ici

Engagement des parties prenantes, cycle de vie et stratégie de mise en marché Communication aux parties prenantes, gestion du cycle de vie et stratégie de mise en marché.

Habilitation des équipes et productivité opérationnelle Configuration des outils d'équipe et pratiques de support opérationnel.

Examiner le module Recommencer