Prouvez-le, 3e partie : un guide étape par étape pour la mise en œuvre du raisonnement automatisé

Dans ce guide, vous découvrirez comment créer une politique de raisonnement automatisé à partir d’un document métier existant, la déployer via les barrières de protection Amazon Bedrock, valider les réponses LLM avec ApplyGuardrail, créer une piste d’audit et sécuriser les agents d’IA avec la politique AgentCore. Grâce à ce processus, les équipes peuvent passer du document de conformité à la vérification de la production en seulement 30 minutes.

Dans la première partie (« Pourquoi « probablement correct » n’est pas suffisant »), nous avons expliqué pourquoi les start-ups ont besoin d’une vérification déterministe. Dans la deuxième partie (« Logique formelle , politiques Cedar et aspects économiques de la vérification »), nous avons expliqué le pipeline de vérification et les mathématiques qui le sous-tendent. Il est maintenant temps de créer.

De quoi avez-vous besoin avant de commencer ?

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Un compte AWS avec accès à Amazon Bedrock. Si vous faites partie d’AWS Activate, vous disposez déjà de crédits pour cela.
• Python 3.9+ avec boto3. Si vous avez expédié un MVP, vous l’avez.
• Un document de politique (PDF, Markdown ou texte brut) décrivant vos règles métier. Si vous avez réussi un examen de conformité ou une vérification préalable des investisseurs, vous l’avez.

Étape 1 : créer votre politique de raisonnement automatisé

Le chemin le plus rapide consiste à utiliser la console AWS. Vous n’avez pas besoin d’écrire de logique formelle, car Bedrock traduit automatiquement votre document source en règles logiques formelles.

1. Ouvrez la console Bedrock et accédez à Raisonnement automatisé dans la barre latérale gauche.
2. Créez une politique. Donnez-lui un nom descriptif (par exemple, politique d’éligibilité hypothécaire).
3. Chargez votre document source. Il s’agit du fichier PDF, Word ou texte brut qui décrit vos règles métier. Pour une start-up fintech, il peut s’agir de votre document sur les critères de prêt. Pour les soins de santé, vos protocoles cliniques.
4. Fournissez des instructions. Rédigez une brève intention décrivant ce que la politique valide et incluez deux à trois exemples de paires questions-réponses. Ils aident le système à comprendre comment les utilisateurs interagiront avec la politique.

Pour les équipes qui préfèrent ne pas utiliser la console, il existe également une interface conversationnelle pour la création de politiques qui vous guide tout au long de la formalisation en langage naturel. Elle comporte quelques prérequis (y compris Kiro-CLI), mais supprime complètement la console du flux de travail.

Exemple d’intention :

Cette politique valide les questions d’éligibilité au prêt hypothécaire. Les utilisateurs demandent si les clients sont éligibles à des types de prêts spécifiques en fonction de leurs informations financières.

Exemple de questions-réponses :

Q : Un client souhaite acheter une maison de 350 000 USD avec un acompte de 30 000 USD. Sont-ils admissibles à un prêt hypothécaire classique ?

R : Non. Les prêts hypothécaires classiques exigent un acompte minimum de 20 % (70 000 USD pour un achat de 350 000 USD).

Consultez le rapport de fidélité :

Une fois que le système a traité votre document, il génère un rapport de fidélité avec deux scores :

• Score de couverture (0,0 à 1,0) : quelle part de votre document source est représentée dans la politique
• Score de précision (0,0 à 1,0) : dans quelle mesure les règles extraites correspondent à l’intention de votre document

Le rapport indique également les variables et règles spécifiques extraites, en s’appuyant sur les déclarations exactes de votre document source. C’est ici que vous vérifiez que le système a bien compris vos règles.

Affinez les descriptions de vos variables à l’aide d’exemples concrets issus de votre application. Testez les questions représentatives, vérifiez comment le système les traduit et améliorez les descriptions lorsque les traductions ne correspondent pas à la cible. Il s’agit du plus gros levier de précision. Incluez des unités, des synonymes, des règles de conversion et une terminologie spécifique au domaine dans la mesure du possible. Une description telle que « L’acompte de l’emprunteur en pourcentage du prix d’achat ; lorsque les utilisateurs mentionnent des montants en dollars, convertissez en utilisant (downPayment/PurchasePrice) * 100 » surpasse « Le montant que l’emprunteur met de côté. »

Il ne s’agit pas d’un effort d’ingénierie en plusieurs sprints. Il faut 30 minutes pour passer de votre document de conformité existant à une politique de raisonnement automatisé fonctionnelle. Répétez sur les descriptions des variables et testez avec des exemples de questions jusqu’à ce que les scores de fidélité et les résultats des tests correspondent à vos attentes.

Pour le chemin de l’API (utile pour les pipelines CI/CD), consultez la référence de l’API CreateAutomatedReasoningPolicy. L’API possède un nom, une description facultative et un élément policyDefinition contenant des règles, des variables et des types personnalisés.

Étape 2 : déploiement sur une barrière de protection

Une fois que votre politique est bien testée, déployez-la pour une utilisation en production.

Enregistrez une version immuable. Dans la console, choisissez « Enregistrer en tant que nouvelle version ». « Cela crée un instantané numéroté et immuable (version 1, 2, 3…) afin que votre barrière de protection ne soit pas affectée lorsque vous continuez à modifier le DRAFT. C’est ainsi que les start-ups expédient rapidement et en toute sécurité : votre équipe de conformité examine la version 1 en production tandis que votre équipe d’ingénierie répète la version 2 en brouillon. Aucun déploiement ne gèle, pas de « veuillez ne pas modifier la politique avant l’expédition ».

Une fois que vous avez publié une version de votre politique, joignez-la à une barrière de protection afin qu’elle puisse être utilisée lors de la validation de l’exécution :

Détails clés :

• policies prend un tableau de chaînes d’ARN de politique (maximum deux), pas d’objets.
• confidenceThreshold (facultatif, 0,0 à 1,0) contrôle le niveau d’accord minimum pour que les traductions soient considérées comme fiables. Des valeurs plus faibles (0,3) mettent en évidence un plus grand nombre de résultats plus rapidement ; des valeurs plus élevées (1,0) optimisent strictement la solidité. Commencez par le bas pendant le développement, puis resserrez pour la production.
• crossRegionConfig est requis pour les vérifications de raisonnement automatisé ; il permet l’inférence interrégionale pour l’évaluation des barrières de protection. Utilisez le profil pour votre zone géographique (par exemple, us.guardrail.v1:0 pour les États-Unis, eu.guardrail.v 1.0 pour l’UE).
• blockedInputMessaging et blockedOutputsMessaging sont obligatoires ; il s’agit des messages de secours affichés lorsque d’autres composants de barrière de protection (et non raisonnement automatisé) bloquent le contenu.
• Utilisez une version numérotée (:1) dans l’ARN pour la production. Réservez DRAFT au développement uniquement

Étape 3 : Valider les réponses LLM avec ApplyGuardRail

Le modèle d’intégration recommandé est l’API autonome ApplyGuardRail. Cela vous donne un contrôle total sur le contenu qui est validé et à quel moment, et c’est l’approche que la documentation AWS recommande explicitement pour les vérifications raisonnement automatisé.

Voici un exemple d’intégration minimale ajouté à votre pipeline d’inférence existant :

Appelez ceci une fois que votre LLM a généré une réponse, avant de la communiquer à l’utilisateur :

Important : les contrôles de raisonnement automatisé fonctionnent en mode détection. Ils renvoient les résultats et les commentaires. Ils ne bloquent ni ne réécrivent la réponse automatiquement. Votre application inspecte les résultats et décide de la marche à suivre.

Étape 4 : gérer les résultats

Chaque résultat est un type d’union avec exactement une clé présente. Voici comment les analyser et agir :

Le modèle de correction standard est une boucle de validation-réécriture : validez la réponse, renvoyez toutes les violations au modèle, régénérez la réponse et revalidez. Répétez l’opération jusqu’à ce que la réponse soit valide ou qu’une limite de nouvelles tentatives soit atteinte.

Votre utilisateur ne voit jamais la boucle de réécriture. Il voit une réponse correcte dès le premier essai. L’itération se produit en quelques millisecondes dans les coulisses.

Étape 5 : créer une piste d’audit

Chaque itération de vérification doit être consignée. Lorsque votre entreprise cliente demande des preuves SOC 2, ou que votre organisme de réglementation vous demande comment vous avez vérifié une décision spécifique, vous extrayez le journal JSON. Chaque vérification est horodatée et traçable.

Ce journal devient votre artefact de conformité. Il montre ce que l’utilisateur a demandé, ce que le LLM a généré, ce que le raisonnement automatisé a trouvé et les mesures prises par votre application. Pour les start-ups qui souhaitent se conformer à la norme SOC 2, à la norme HIPAA ou aux ventes aux entreprises, cette piste d’audit n’est pas facultative. C’est la preuve que votre système fonctionne comme indiqué.

Étape 6 : sécuriser vos agents avec la politique AgentCore

Si votre start-up est passée des chatbots à des flux de travail agentiques (votre IA prend des rendez-vous, traite les remboursements, interroge des bases de données ou envoie des e-mails), vous devez définir des limites quant à ce que votre agent peut faire, et pas seulement à ce qu’il dit.

Policy dans Amazon Bedrock AgentCore utilise Cedar pour définir ces limites. Par exemple, un agent de prise de rendez-vous médicaux a besoin de politiques qui limitent les dossiers des patients auxquels il peut accéder, limitent les actions de planification aux heures ouvrables et l’empêchent de traiter les remboursements supérieurs à un certain seuil sans l’approbation du responsable. Démarrez en mode LOG_ONLY pour observer ce que fait votre agent sans rien bloquer. Une fois que vous avez confiance dans les politiques, passez en mode ENFORCE pour la production.

La passerelle est la couche d’application entre votre agent et ses outils. Chaque invocation d’outil passe par la passerelle, où les politiques Cedar sont évaluées avant que la demande n’atteigne la cible. C’est pourquoi l’application est déterministe et indépendante du raisonnement de l’agent : l’agent ne peut pas contourner, ignorer ou franchir la passerelle par la voix.

Configurez une passerelle et un moteur de politiques à l’aide de l’interface de ligne de commande AgentCore :

Rédigez une politique Cedar et joignez-la au moteur de politique. L’exemple suivant montre des politiques illustratives pour un agent de rendez-vous médical. En pratique, les noms de vos actions sont générés automatiquement à partir de la cible et du schéma de l’outil de votre passerelle (par exemple, HealthTarget__get_patient_record), et la ressource doit faire référence à l’ARN de votre passerelle spécifique :

Cedar fonctionne selon le principe du refus par défaut : toute interaction entre un agent et un outil est bloquée, sauf si une politique d’autorisation explicite l’autorise. Vos politiques d’autorisation définissent les outils que l’agent peut appeler et dans quelles conditions. Les politiques d’interdiction ci-dessous prévoient des exceptions, bloquant ainsi certains scénarios spécifiques même lorsqu’une autorisation plus générale les autoriserait par ailleurs.

Enregistrez ceci sous le nom healthcare_policy.cedar, puis attachez-le au moteur de politique :

Vous pouvez également décrire vos règles en langage naturel et laisser le système générer Cedar pour vous (la passerelle doit d’abord être déployée) :

Le raisonnement automatisée valide les politiques au moment de leur création, en détectant les règles trop permissives, trop restrictives ou inefficaces avant le déploiement.

Les principales propriétés pour les start-ups réglementées :

• Refus par défaut  : si aucune politique n’autorise explicitement une action, celle-ci est bloquée
• Interdire l’emporte toujours  : les règles strictes ne peuvent pas être contournées par d’autres politiques
• Application déterministe  : fonctionne à la limite de la passerelle, en dehors du raisonnement de votre agent. Ne peut pas être contourné par une injection d’invite, une hallucination ou des bugs

Démarrez en mode LOG_ONLY pour voir ce que fait votre agent sans endommager votre produit. Les journaux indiquent la politique appliquée à chaque demande adressée à la passerelle, le résultat de la décision politique (autoriser ou refuser) et font apparaître des politiques non concordantes en cas de dérive de l’outil. Révisez-les. Affinez les politiques. Lorsque vous êtes en confiance, passez à ENFORCE. C’est ainsi que vous passez du prototype à la production sans perturber vos utilisateurs.

Pour des exemples complets, notamment des scripts de déploiement et des harnais de test, consultez les exemples Amazon Bedrock AgentCore sur GitHub.

Que se passe-t-il une fois que vous déployez le raisonnement automatisé ?

Une fois que les contrôles de raisonnement automatisé et la politique AgentCore sont en cours d’exécution, vous débloquez quelque chose de plus précieux que la prévention des erreurs : une source unique de vérité.

Votre politique de raisonnement automatisé correspond à vos règles métier codifiées sous forme de logique formelle. Lorsque ces règles changent (et c’est toujours le cas : nouvelles réglementations, critères d’octroi de crédit actualisés, protocoles cliniques révisés), vous mettez à jour le document source, régénérez la politique, et immédiatement, tous les systèmes d’IA de votre infrastructure se conforment aux nouvelles règles. Pas besoin d’ingénierie de requête. Pas besoin de réentraîner les modèles. Pas besoin d’espérer que quelqu’un ait pensé à modifier le prompt du système.

Cela élimine toute une catégorie de bugs liés à la dérive. Votre documentation et le comportement de votre IA sont mathématiquement liés. Ils ne peuvent pas se désynchroniser.

Les barrières de protection étant indépendantes du modèle, votre couche de vérification reste la même lorsque vous changez de modèle de base. La même politique de raisonnement automatisé qui a vérifié les réponses de Claude vérifie également celles d’Amazon Nova. Les règles dépendent de votre logique métier, et non du modèle.

Cette intégration s’étend à l’ensemble de l’écosystème Bedrock : les politiques de raisonnement automatisé s’associent aux bases de connaissances pour la génération augmentée par la recherche, aux agents AgentCore pour les flux de travail en plusieurs étapes, ainsi qu’à toute la gamme des modèles de base. Vous développez votre solution sur une plateforme, et non sur une solution ponctuelle.

En savoir plus

• Documentation relative aux vérifications du raisonnement automatisé
• Concepts de raisonnement automatisé (variables, règles, résultats)
• Guide d’intégration (modèles ApplyGuardrail)
• Documentation sur la politique AgentCore
• Exemples AgentCore sur GitHub
• Présentation d’AWS Provable Security
• Qu’est-ce que le raisonnement automatisé
• Langage Cedar (CNCF)

C’est la fin de notre série sur le raisonnement automatisé pour les start-ups

Dans toute la série Prove It, notre thèse est restée la même : les start-ups qui s’appuient sur l’IA ont besoin d’une vérification mathématique déterministe, et pas seulement de garanties probabilistes.

Dans la première partie, nous avons expliqué pourquoi le problème de confiance est existentiel pour les start-ups et comment les décennies de travail d’AWS dans le domaine des méthodes formelles ont conduit aux barrières de protection Bedrock et à la politique AgentCore.

Dans la deuxième partie, nous avons examiné en détail la logique formelle, le pipeline de vérification et les aspects économiques. Dans cet article, vous avez pu découvrir le parcours complet de mise en œuvre, depuis les documents de conformité existants jusqu’à une IA vérifiée et prête à être déployée en production.

Les start-ups qui s’imposeront à l’ère de l’IA ne se contenteront pas de développer des systèmes intelligents ; elles mettront au point des systèmes dont elles pourront prouver l’exactitude. Le raisonnement automatisé et AgentCore Policy permettent déjà d’y parvenir aujourd’hui, en s’appuyant sur les politiques et les documents de conformité dont disposent déjà la plupart des entreprises. La seule question qui reste est la suivante : allez-vous vous lancer dès maintenant, ou attendre que le premier incident vous y oblige ?