Amazon AWS automatise la réparation des politiques Bedrock, mais les humains gardent le dernier mot

Amazon AWS a ajouté deux parcours d’affinage automatique pour les politiques Bedrock Automated Reasoning, malgré les risques liés au fait de laisser un logiciel réécrire sa propre logique de conformité. Le système peut diagnostiquer des tests échoués, proposer des corrections de règles formelles et améliorer les formulations dont la traduction est ambiguë. Toutefois, aucune modification proposée ne prend effet avant qu’une personne ne l’examine et l’accepte.

Cette limite d’approbation est l’élément le plus important de l’annonce. Amazon Bedrock peut désormais accomplir une plus grande part du travail de diagnostic qui exigeait auparavant que des spécialistes inspectent manuellement les variables, les règles, les types et les résultats des tests. AWS automatise la proposition de réparation, sans transférer la responsabilité des politiques à une boucle d’optimisation opaque.

Cette évolution met sous pression les flux de rédaction manuelle de règles, notamment les équipes qui s’appuient sur des feuilles de calcul, des contrôles fondés sur des prompts ou des experts modifiant à la main des expressions formelles. Elle met également à l’épreuve une promesse plus vaste d’Automated Reasoning : les entreprises peuvent obtenir des garanties plus solides qu’avec une évaluation classique des modèles, sans transformer chaque mise à jour de politique en projet de méthodes formelles.

Ce qu’Amazon AWS a modifié dans l’affinage des politiques Bedrock

Le nouveau flux transforme un test de politique échoué en proposition de réparation révisable, au lieu de ne laisser aux utilisateurs qu’un résultat de diagnostic.

Une politique Automated Reasoning représente les exigences d’un domaine sous forme de variables, de types personnalisés et de règles logiques. Bedrock utilise cette définition formelle pour vérifier si une affirmation générée par l’IA découle des exigences encodées. Cette approche diffère d’un évaluateur fondé sur un modèle, qui estime la qualité au moyen d’un autre modèle probabiliste.

AWS a introduit les contrôles Automated Reasoning en préversion lors de re:Invent 2024. Le service a ensuite atteint la disponibilité générale avec la gestion des tests, la génération de scénarios et une prise en charge élargie des documents. AWS indique que ses contrôles de raisonnement peuvent traiter des documents sources contenant jusqu’à 120 000 tokens, soit environ 100 pages.

La dernière capacité d’affinage répond à ce qui se passe lorsque les équipes découvrent qu’une politique ne se comporte pas comme prévu. Un test peut échouer parce qu’une règle formelle ne comporte pas de condition. Il peut aussi échouer parce que Bedrock associe le langage courant à la mauvaise variable ou trouve plusieurs traductions plausibles.

Il s’agit de catégories d’échec différentes ; AWS propose donc deux parcours d’affinage :

• L’affinage des règles traite la structure formelle de la politique. Il peut proposer des ajouts, des mises à jour ou des suppressions portant sur les règles, les variables et les types personnalisés.

• L’affinage du langage traite les descriptions ambiguës ou imprécises. Il peut réviser les descriptions des variables et les définitions de types afin que les traductions ultérieures associent plus systématiquement le langage aux concepts de la politique.

Les deux parcours produisent des modifications proposées au lieu d’écraser immédiatement la définition active. Dans la console, les utilisateurs accèdent à un écran de révision avant d’accepter le résultat. Via l’API, les applications récupèrent la définition de politique générée, puis mettent explicitement à jour le brouillon.

Cette séparation est importante, car une réparation syntaxiquement valide peut toujours encoder une mauvaise décision métier. Une politique d’avantages sociaux peut être correctement compilée tout en appliquant un seuil d’ancienneté erroné. Une politique financière peut supprimer un conflit apparent qui représente en réalité une exception intentionnelle.

L’annonce modifie donc le goulot d’étranglement de la rédaction, et non le modèle de responsabilité. Bedrock peut inspecter l’échec et préparer la réparation. Un responsable du domaine décide toujours si la logique proposée correspond à la source faisant autorité.

AWS documente plusieurs états possibles du flux, notamment SCHEDULED, PREPROCESSING, BUILDING, TESTING, COMPLETED et FAILED. L’identifiant de flux renvoyé permet à un client de surveiller ce processus asynchrone avant de demander les ressources qui en résultent.

Le service génère également un rapport de qualité après une compilation. Ce rapport peut identifier des problèmes structurels tels que des descriptions ambiguës, des groupes de règles déconnectés, des variables inutilisées et des relations contradictoires. Ces signaux aident les équipes à distinguer un échec de test local d’un défaut de modélisation plus large.

Cela crée une boucle plus complète : encoder un document source, exécuter des tests, examiner les échecs, demander une réparation, réviser la définition proposée et relancer la suite. Cette boucle existait déjà, mais une plus grande part de son travail de diagnostic et de traduction se déroule désormais dans Bedrock.

L’affinage des règles transforme les retours des tests en modifications formelles

L’affinage des règles est le mode le plus conséquent, car il peut modifier la logique qui détermine si une affirmation réussit ou échoue.

Prenons une politique de congé des employés. Le document source indique qu’un employé à temps plein devient admissible au congé parental uniquement après plus de 12 mois de service. La politique générée contient plutôt cette expression :

Cette règle omet l’ancienneté. Un test impliquant un employé à temps plein récemment embauché renverrait une approbation alors que le résultat attendu est un refus. L’échec n’est pas un problème de langage uniquement. Le modèle formel ne comporte ni variable pertinente ni condition requise.

AWS décrit les annotations comme des corrections ciblées attachées aux éléments de la politique. Les opérations prises en charge incluent l’ajout, la mise à jour ou la suppression de variables, de règles et de types personnalisés. Un utilisateur peut aussi soumettre une règle en anglais courant via addRuleFromNaturalLanguage, permettant à Bedrock de la traduire en logique formelle.

La définition corrigée pourrait ajouter une variable entière nommée tenureMonths et remplacer l’expression d’origine par :

Le flux dans la console commence dans la suite de tests de la politique :

1. Ouvrez une politique Automated Reasoning dans la console Amazon Bedrock.

2. Sélectionnez un test échoué et examinez ses résultats.

3. Confirmez que les prémisses, l’affirmation et le résultat attendu représentent le scénario visé.

4. Modifiez les conditions du test si le test lui-même est incomplet.

5. Relancez le test pour vérifier que le scénario révisé exprime le comportement attendu.

6. Choisissez l’option permettant d’appliquer des annotations ou d’affiner la politique.

7. Laissez Bedrock lancer un flux de compilation de politique à partir du retour du test.

8. Examinez chaque modification proposée des règles, variables et types.

9. N’acceptez les modifications que lorsqu’elles correspondent à la politique source.

10. Relancez les tests enregistrés et les scénarios générés sur le brouillon révisé.

Les troisième et quatrième étapes méritent une attention particulière. Un test échoué ne prouve pas toujours que la politique est erronée. Le test peut omettre une prémisse nécessaire, utiliser un résultat attendu inexact ou formuler l’affirmation d’une manière qui en modifie le sens.

AWS recommande donc d’examiner le résultat avant d’appliquer des annotations. Ses conseils d’affinage invitent les utilisateurs à modifier et relancer d’abord le test lorsque cela est approprié. Si le test révisé produit le résultat attendu, ce retour peut étayer une annotation ciblée.

L’API expose la même capacité via StartAutomatedReasoningPolicyBuildWorkflow. Les réparations de règles utilisent le type de flux REFINE_POLICY. La requête doit inclure la définition complète actuelle de la politique, et non uniquement l’élément modifié.

Une requête AWS CLI simplifiée ressemble à ceci :

Une requête de production remplacerait les tableaux vides par la définition complète du brouillon. La version du schéma de politique doit être 1.0, distincte de la version DRAFT ou numérotée de la ressource.

La réponse réussie contient deux valeurs :

L’application peut interroger le flux avec GetAutomatedReasoningPolicyBuildWorkflow ou examiner les flux au moyen de l’opération de liste. Une fois le traitement terminé, elle récupère la définition de politique générée via GetAutomatedReasoningPolicyBuildWorkflowResultAssets.

Une commande de récupération typique suit ce modèle :

La récupération ne rend pas la définition proposée faisant autorité. Le client doit comparer le résultat avec le brouillon actuel, présenter les différences à un réviseur autorisé et relancer les tests pertinents.

Après approbation, le client peut appeler UpdateAutomatedReasoningPolicy avec la définition révisée. Cette mise à jour explicite est l’équivalent, dans l’API, de l’acceptation des modifications dans la console.

Le flux prend en charge des opérations plus précises que le remplacement aveugle d’une politique entière. Les annotations de variables comprennent addVariable, updateVariable et deleteVariable. Les annotations de règles comprennent addRule, updateRule, deleteRule et addRuleFromNaturalLanguage.

Les opérations sur les types personnalisés couvrent les ajouts, les mises à jour et les suppressions. Des annotations de retour telles que updateFromRulesFeedback et updateFromScenarioFeedback permettent aux utilisateurs de décrire comment une règle ou un scénario s’est comporté de manière incorrecte.

Cette gamme est utile, mais elle accroît la charge de révision. La suppression d’une variable en double peut améliorer la cohérence de la traduction. La suppression d’une règle d’apparence similaire peut également effacer une exception intentionnelle. Chaque proposition exige un examen sémantique, même lorsque l’expression générée passe les contrôles structurels de Bedrock.

L’affinage du langage corrige l’ambiguïté avant qu’elle n’atteigne le solveur

L’affinage du langage cible la frontière où des phrases ordinaires deviennent des prémisses et des affirmations formelles, souvent la source la moins visible des échecs de politique.

La logique formelle ne peut évaluer que les concepts qui lui sont fournis. Avant cette évaluation, Bedrock doit traduire l’entrée d’un utilisateur et une réponse d’IA dans les variables définies par la politique.

Des descriptions ambiguës fragilisent cette étape de traduction. Supposons qu’une politique contienne à la fois tenureMonths et monthsOfService, avec des descriptions presque identiques. La phrase « Elle travaille ici depuis deux ans » pourrait être associée à l’une ou l’autre variable.

La règle sous-jacente peut être correcte, mais un test peut tout de même renvoyer TRANSLATION_AMBIGUOUS. Ce résultat signifie que le système a trouvé plus d’une interprétation formelle plausible. Il ne signifie pas que l’affirmation est valide ou invalide.

L’affinage du langage examine les descriptions et les types personnalisés afin de détecter ces chevauchements. Il propose des formulations plus claires, des concepts fusionnés ou d’autres modifications de définition visant à réduire l’ambiguïté. L’objectif n’est pas une amélioration stylistique. Il s’agit d’un mappage plus stable entre le langage naturel et le schéma formel.

Le flux dans la console est plus court qu’une réparation ciblée de règle :

1. Ouvrez la politique Automated Reasoning dans la console Bedrock.

2. Accédez à la page Definitions.

3. Examinez les avertissements du rapport de qualité.

4. Choisissez Resolve ambiguities.

5. Attendez que Bedrock analyse les descriptions de variables et les définitions de types.

6. Examinez les modifications de langage proposées.

7. Comparez chaque proposition avec le document source d’origine.

8. N’acceptez que les modifications qui préservent le sens visé.

9. Relancez les tests contenant des formulations variées et des cas limites.

L’API utilise le même point de terminaison de flux de compilation, mais le type de flux est RESOLVE_POLICY_AMBIGUITIES. La requête inclut la définition complète actuelle :

Le client surveille ensuite le flux et récupère la définition proposée avec le type de ressource POLICY_DEFINITION. Il peut également récupérer la ressource QUALITY_REPORT afin de comprendre quels problèmes structurels ont motivé la recommandation.

L’API de flux de compilation traite le contenu du flux comme une union. Un seul membre de contenu pris en charge peut apparaître dans une requête. Les clients ne doivent pas combiner le contenu de résolution d’ambiguïtés avec une autre charge utile de flux en s’attendant à ce que les deux opérations s’exécutent ensemble.

Le raffinement linguistique diffère également de ITERATIVELY_REFINE_POLICY. Le flux de travail itératif utilise un document source et un retour en langage naturel facultatif pour améliorer une politique existante. Il convient lorsque le document faisant autorité change ou lorsque les utilisateurs souhaitent orienter un raffinement plus large d’une politique.

Par exemple, une version révisée d’un manuel de l’employé peut abaisser un seuil d’ancienneté et ajouter un congé de deuil. Un client peut fournir la définition actuelle complète, le document mis à jour et un retour décrivant ces changements.

Une requête simplifiée suit cette structure :

AWS distingue cette opération de INGEST_CONTENT. Le raffinement itératif utilise un document comme contexte pour améliorer une définition existante. L’ingestion extrait de nouvelles règles à partir de nouveaux contenus et peut les fusionner dans une politique existante.

Cette distinction évite une erreur d’implémentation fréquente. Un nouveau chapitre de manuel doit généralement passer par l’ingestion. Un chapitre révisé destiné à corriger une logique existante relève du raffinement itératif.

La correction du langage doit toujours être testée avec plusieurs formulations. Une description révisée peut éliminer une ambiguïté tout en en créant une autre. Les équipes doivent inclure des synonymes, des termes abrégés, des énoncés négatifs et des valeurs proches des seuils de décision.

Un enregistrement consultable des clauses sources, des preuves de test et des révisions acceptées aide également les réviseurs à reconstituer les raisons d’une modification de définition. Les équipes d’ingénierie peuvent organiser ces éléments dans une base de connaissances technique plutôt que de séparer les décisions de politique de leurs documents justificatifs.

L’approbation humaine est une fonctionnalité, pas une limitation

Le diagnostic automatique réduit le coût de maintenance des politiques formelles, mais le mécanisme d’approbation empêche qu’une erreur d’optimisation ne devienne une règle organisationnelle.

La vérification formelle est parfois présentée comme une certitude mathématique. Cette expression doit être nuancée : le moteur peut raisonner rigoureusement sur la politique formelle qu’il reçoit. Il ne peut pas garantir que cette politique représente parfaitement la législation, les recommandations cliniques, les contrats ou les procédures internes.

C’est le problème classique de la spécification. Un solveur peut déterminer correctement qu’un résultat découle d’une règle défaillante. Les mathématiques valident la cohérence avec le modèle, non la véracité des hypothèses sources du modèle.

Le raffinement automatique ne supprime pas cette limitation. Il peut détecter le chevauchement de deux variables, l’absence de connexion dans un ensemble de règles ou l’indication, par un test échoué, d’une condition manquante. Il ne peut pas décider de manière autonome quelle interprétation reflète la politique légitime de l’organisation.

L’écran de révision humaine remplit donc trois fonctions.

Premièrement, il instaure un contrôle des changements. Les réviseurs peuvent voir si Bedrock propose l’ajout d’une condition, la suppression d’une règle, le renommage d’une variable ou la modification d’une définition de type.

Deuxièmement, il préserve l’appropriation par le domaine métier. Un ingénieur peut valider la syntaxe et le comportement du flux de travail, tandis qu’un juriste, un clinicien, un responsable conformité ou le propriétaire de la politique valide le sens.

Troisièmement, il permet d’établir une piste d’audit. Les équipes peuvent conserver le test défaillant, l’annotation proposée, la définition acceptée et les résultats de test ultérieurs comme preuves des raisons ayant conduit à une modification de politique.

La documentation d’AWS recommande elle-même une révision humaine des informations de politique générées. L’extraction à partir de documents en langage naturel est non déterministe ; des exécutions distinctes peuvent donc produire des différences dans les règles, les variables et les types.

Le modèle opérationnel le plus sûr utilise au moins quatre contrôles :

• Exiger l’approbation d’un propriétaire de politique identifié pour les modifications sémantiques.

• Comparer la définition proposée à la fois avec la version actuelle et avec la clause source.

• Relancer l’intégralité de la suite de régression, et non uniquement le test ayant déclenché le raffinement.

• Publier une version numérotée de la politique uniquement après la révision et la finalisation des tests.

Les applications doivent également utiliser un jeton d’idempotence lors du démarrage des flux de travail. Le clientRequestToken facultatif empêche les nouvelles tentatives de créer des opérations en double lorsque le même jeton est réutilisé.

Les limites des flux de travail exigent aussi une planification. La documentation d’AWS indique qu’une politique prend en charge au maximum deux flux de création, avec un seul flux en cours à la fois. Un client peut devoir supprimer un ancien flux avant d’en lancer un autre.

Le chiffrement et les contrôles d’accès restent pertinents, car les définitions de politique peuvent contenir une logique métier sensible. Bedrock prend en charge les clés AWS KMS gérées par le client, mais l’identité appelante et la politique de clé doivent accorder les autorisations requises de déchiffrement, de description et de clés de données.

Ces garde-fous ne rendent pas la maintenance des politiques automatique au sens courant du terme. Ils en font une automatisation supervisée. Le système réalise l’analyse et génère un artefact candidat, tandis qu’une personne contrôle le changement d’état.

Ce modèle est plus défendable que des garde-fous auto-modifiants. Si un échec de production affaiblissait automatiquement la règle qui l’a détecté, des attaquants pourraient potentiellement influencer la politique au moyen d’entrées conçues à cette fin ou de retours trompeurs.

Un mécanisme de révision interrompt cette voie. Il permet également aux équipes de rejeter des corrections qui augmentent les taux de réussite aux tests en rendant la politique formelle moins fidèle à sa source.

La question sceptique est de savoir si les organisations traiteront la révision comme un véritable contrôle ou comme un écran de confirmation de routine. Les propositions automatiques peuvent créer un biais d’automatisation, en particulier lorsque les réviseurs manquent d’expérience dans la lecture d’expressions formelles.

Les équipes doivent présenter les modifications proposées sous plusieurs formes : l’expression formelle, une explication en langage courant, la clause source et les scénarios de test concernés. Un bouton d’acceptation vert dépourvu de ce contexte déplacerait le goulot d’étranglement au lieu de le résoudre.

La pression passe de l’écriture de la logique à la gouvernance des changements

Amazon AWS rend la correction des politiques formelles plus accessible, mais les organisations doivent désormais mettre en place des pratiques de révision à la hauteur de l’accélération du rythme des changements.

Le concurrent immédiat n’est ni une plateforme cloud ni un fournisseur de modèles en particulier. C’est la voie manuelle qu’empruntent de nombreuses équipes de gouvernance : rédiger les règles à la main, examiner individuellement les cas défaillants et dépendre d’un petit groupe de spécialistes pour corriger le modèle formel.

Les garde-fous fondés sur des prompts offrent une autre voie. Ils peuvent indiquer à un modèle de suivre une politique ou demander à un second modèle d’évaluer la conformité. Ces méthodes sont plus simples à adopter, mais leurs décisions restent probabilistes et peuvent varier selon la formulation ou les versions de modèle.

Automated Reasoning utilise des variables et des contraintes explicites. Cette structure permet les contre-exemples, l’analyse de satisfaisabilité et des conclusions auditables. Elle exige également une spécification fidèle, ce qui engendre davantage de travail de configuration et de maintenance.

Le raffinement vise ce coût de maintenance. Si Bedrock transforme de manière fiable les retours de test en correctifs ciblés et révisables, les experts métier peuvent consacrer moins de temps à traduire le langage courant des politiques en expressions de solveur.

Un cas client AWS rapporté illustre le résultat recherché. Le fournisseur de services financiers PitCrew affirme avoir encodé 40 politiques Automated Reasoning et en utiliser des combinaisons dans trois agents de production. Son flux de conformité vérifie les supports marketing et les formulaires réglementaires au regard de contraintes formelles.

Selon l’entreprise, un processus de révision est passé de deux semaines à 30 minutes. Les contenus marketing et sociaux qui entraient auparavant dans une file d’attente de trois jours seraient désormais validés en 30 secondes. Il s’agit de résultats rapportés par un client pour une implémentation spécifique, et non de garanties générales de performance.

Ce cas d’usage montre pourquoi le raffinement est important. Les documents réglementaires changent, les politiques clients diffèrent et des cas limites apparaissent après le déploiement. Une politique qui ne peut pas être corrigée efficacement finira soit par devenir obsolète, soit par accumuler des exceptions manuelles en dehors du système formel.

Toutefois, des corrections plus rapides peuvent également accroître le renouvellement des politiques. Une équipe peut accepter des ajustements locaux fréquents sans vérifier l’incidence de chaque changement sur d’autres groupes de règles. Au fil du temps, la définition peut devenir cohérente en interne tout en restant difficile à comprendre pour les humains.

Le rapport de qualité peut aider à identifier les ensembles de règles déconnectés, les éléments contradictoires et les descriptions ambiguës. Il ne peut pas remplacer une discipline de versionnage ou les tests de régression.

Les organisations qui évaluent cette fonctionnalité doivent mesurer davantage que le nombre de suggestions acceptées. Parmi les indicateurs utiles figurent :

• Le pourcentage de modifications proposées acceptées sans modification.

• Le pourcentage rejeté parce qu’il modifie le sens recherché.

• Les échecs de régression introduits par une correction acceptée.

• L’ambiguïté de traduction entre des formulations utilisateurs réalistes.

• Le délai entre un test échoué et une mise à jour de politique révisée.

• Les divergences entre les approbations du propriétaire métier et de l’ingénieur.

Ces mesures révèlent si le raffinement réduit le travail des experts ou le transfère simplement vers la révision. Elles mettent également en évidence les cas où le moteur propose à répétition des modifications plausibles mais sémantiquement incorrectes.

La fonctionnalité devrait être particulièrement pertinente pour les applications réglementées, où les règles ont des sources faisant autorité et où les décisions nécessitent des explications. L’éligibilité aux soins de santé, les communications financières, les avantages sociaux, la couverture d’assurance et les exigences contractuelles correspondent à ce modèle.

Elle est moins adaptée aux préférences générales telles que « être utile » ou « rédiger un texte engageant ». Ces objectifs ne disposent pas des variables et contraintes précises nécessaires à une évaluation formelle.

Le principal compromis reste celui entre capacité et gouvernance. La correction automatique élargit le nombre de personnes pouvant participer à l’élaboration des politiques. Elle augmente également le nombre de changements que les réviseurs pourraient approuver sans en retracer pleinement les conséquences.

Ce qu’il faut surveiller après l’automatisation du raffinement par Amazon AWS

Le prochain test sera de déterminer si les propositions de Bedrock restent ciblées, explicables et fidèles lorsque les politiques dépassent les exemples contrôlés.

Le premier signal sera la qualité d’acceptation dans les déploiements réels. AWS devrait montrer à quelle fréquence les experts métier acceptent les corrections proposées sans les modifier, les révisent ou les rejettent. Un taux d’acceptation élevé accompagné de résultats de régression stables étayerait l’affirmation selon laquelle le raffinement réduit le travail de rédaction formelle.

Un taux de rejet élevé indiquerait que le diagnostic est utile, mais que la correction sémantique reste l’affaire de spécialistes. L’acceptation seule ne suffit pas, car les réviseurs peuvent approuver de mauvaises suggestions. Les résultats doivent inclure les régressions et les constats de production ultérieurs.

Le deuxième signal sera constitué par les preuves issues de politiques vastes et interconnectées. Les exemples publiés utilisent des règles compréhensibles, telles que l’éligibilité aux congés et l’évaluation des risques hospitaliers. Les définitions d’entreprise peuvent contenir des exceptions, des renvois croisés, des types personnalisés et des exigences interagissant entre de nombreuses sections.

Une correction qui résout un scénario défaillant peut modifier les conséquences de plusieurs règles éloignées. Les tests doivent révéler si le moteur identifie cet impact plus large et si son interface de révision rend ces effets visibles.

Le troisième signal concernera la manière dont AWS étend l’intégration et la gouvernance. Parmi les ajouts utiles figureraient des différences de politiques plus riches, des rôles d’approbation, des réviseurs obligatoires, la traçabilité des clauses sources et des liens plus clairs entre les changements acceptés et les tests concernés.

La gouvernance inter-comptes mérite également de l’attention. AWS a étendu les garde-fous Bedrock centralisés, mais a documenté des limites concernant les contrôles Automated Reasoning dans certains scénarios d’application inter-comptes. Un support plus large déterminera si les grandes organisations peuvent gouverner ces politiques de manière cohérente entre les équipes.

Pour les développeurs, l’action immédiate est pragmatique. Commencez par une politique limitée, conservez le document faisant autorité et créez des tests pour les approbations attendues, les refus, les ambiguïtés et les cas limites. Ne déclenchez le raffinement des règles qu’après avoir confirmé que le test lui-même est correct.

Examinez ensuite chaque proposition comme une décision de politique, et non comme une simple commodité de génération de code. Récupérez la définition de politique et le rapport de qualité, comparez-les à la version actuelle, relancez l’intégralité de la suite et versionnez le résultat accepté.

Pour les acheteurs d’entreprise, demandez qui approuve les modifications et comment les propositions rejetées sont consignées. Demandez si les réviseurs voient conjointement les diffs formels, des explications en langage clair, les éléments de preuve issus des sources et l’impact sur les régressions.

Amazon AWS a raccourci le chemin entre l’échec et une correction potentielle. La question la plus difficile reste organisationnelle : votre équipe peut-elle examiner les modifications formelles de politiques avec autant de rigueur que Bedrock peut désormais les générer ?