Amazon AWS automatizza la riparazione delle policy di Bedrock, ma gli esseri umani mantengono l'ultima parola
- Aisha Washington
- 60 minuti fa
- Tempo di lettura: 14 min
Amazon AWS ha aggiunto due percorsi di perfezionamento automatico per le policy di Bedrock Automated Reasoning, nonostante i rischi di lasciare che il software riscriva autonomamente la propria logica di conformità. Il sistema può diagnosticare test non riusciti, proporre correzioni formali alle regole e migliorare le formulazioni che si traducono in modo ambiguo. Tuttavia, nessuna modifica proposta entra in vigore finché una persona non la esamina e la accetta.
Questo confine di approvazione è la parte più importante dell'annuncio. Amazon Bedrock può ora svolgere una porzione maggiore del lavoro diagnostico che in precedenza richiedeva agli specialisti di ispezionare manualmente variabili, regole, tipi e risultati dei test. AWS sta automatizzando la proposta di riparazione, non trasferendo la titolarità delle policy a un ciclo di ottimizzazione opaco.
La mossa mette sotto pressione i flussi di lavoro basati sulla scrittura manuale delle regole, compresi i team che si affidano a fogli di calcolo, controlli basati su prompt o esperti che modificano a mano espressioni formali. Mette inoltre alla prova una promessa più ampia alla base di Automated Reasoning: le aziende possono ottenere garanzie più solide della normale valutazione dei modelli senza trasformare ogni aggiornamento delle policy in un progetto di metodi formali.
Cosa ha cambiato Amazon AWS nel perfezionamento delle policy di Bedrock
Il nuovo flusso di lavoro trasforma un test di policy non riuscito in una proposta di riparazione revisionabile, anziché lasciare agli utenti soltanto un risultato diagnostico.
Una policy di Automated Reasoning rappresenta i requisiti di dominio come variabili, tipi personalizzati e regole logiche. Bedrock utilizza questa definizione formale per verificare se un'affermazione generata dall'AI segue i requisiti codificati. Questo differisce da un valutatore basato su modelli, che stima la qualità tramite un altro modello probabilistico.
AWS ha introdotto i controlli di Automated Reasoning in anteprima a re:Invent 2024. Il servizio ha poi raggiunto la disponibilità generale con gestione dei test, generazione di scenari e gestione ampliata dei documenti. AWS afferma che i suoi reasoning checks possono elaborare materiale sorgente contenente fino a 120.000 token, ovvero circa 100 pagine.
La più recente funzionalità di perfezionamento affronta ciò che accade dopo che i team scoprono che una policy non si comporta come previsto. Un test potrebbe fallire perché nella regola formale manca una condizione. Potrebbe anche fallire perché Bedrock associa il linguaggio ordinario alla variabile sbagliata o trova più di una traduzione plausibile.
Si tratta di classi di errore diverse, quindi AWS offre due percorsi di perfezionamento:
Il perfezionamento delle regole interviene sulla struttura formale della policy. Può proporre aggiunte, aggiornamenti o eliminazioni che riguardano regole, variabili e tipi personalizzati.
Il perfezionamento linguistico interviene su descrizioni ambigue o imprecise. Può rivedere le descrizioni delle variabili e le definizioni dei tipi affinché le traduzioni successive associno il linguaggio ai concetti della policy in modo più coerente.
Entrambi i percorsi producono modifiche proposte anziché sovrascrivere immediatamente la definizione attiva. Nella console, gli utenti accedono a una schermata di revisione prima di accettare il risultato. Tramite l'API, le applicazioni recuperano la definizione della policy generata e quindi aggiornano esplicitamente la bozza.
Questa separazione è importante perché una riparazione sintatticamente valida può comunque codificare una decisione aziendale errata. Una policy sui benefit per i dipendenti potrebbe compilarsi correttamente applicando però una soglia di anzianità errata. Una policy finanziaria potrebbe rimuovere un conflitto apparente che in realtà rappresenta un'eccezione intenzionale.
L'annuncio modifica quindi il collo di bottiglia della creazione, non il modello di responsabilità. Bedrock può ispezionare l'errore e redigere la riparazione. Un responsabile di dominio decide ancora se la logica proposta corrisponde alla fonte autorevole.
AWS documenta diversi possibili stati del flusso di lavoro, tra cui SCHEDULED, PREPROCESSING, BUILDING, TESTING, COMPLETED e FAILED. L'identificatore del flusso di lavoro restituito consente a un client di monitorare questo processo asincrono prima di richiedere gli asset risultanti.
Il servizio genera inoltre un report di qualità dopo una build. Tale report può identificare problemi strutturali quali descrizioni ambigue, gruppi di regole disconnessi, variabili inutilizzate e relazioni contraddittorie. Questi segnali aiutano i team a distinguere un errore locale di test da un difetto di modellazione più ampio.
Questo crea un ciclo più completo: codificare un documento sorgente, eseguire i test, ispezionare gli errori, richiedere una riparazione, esaminare la definizione proposta e rieseguire la suite. Il ciclo esisteva già, ma ora una parte maggiore del suo lavoro diagnostico e di traduzione risiede all'interno di Bedrock.
Il perfezionamento delle regole trasforma il feedback dei test in modifiche formali
Il perfezionamento delle regole è la modalità più rilevante perché può modificare la logica che determina se un'affermazione supera o non supera la verifica.
Consideriamo una policy sui congedi dei dipendenti. Il documento sorgente afferma che un dipendente a tempo pieno diventa idoneo al congedo parentale solo dopo più di 12 mesi di servizio. La policy generata contiene invece questa espressione:
Questa regola omette l'anzianità. Un test che coinvolge un dipendente a tempo pieno appena assunto restituirebbe un'approvazione quando il risultato atteso è il rifiuto. L'errore non riguarda soltanto il linguaggio. Nel modello formale mancano sia una variabile pertinente sia una condizione necessaria.
AWS descrive le annotazioni come correzioni mirate associate agli elementi della policy. Le operazioni supportate includono l'aggiunta, l'aggiornamento o l'eliminazione di variabili, regole e tipi personalizzati. Un utente può anche inviare una regola in linguaggio naturale tramite addRuleFromNaturalLanguage, consentendo a Bedrock di tradurla in logica formale.
La definizione corretta potrebbe aggiungere una variabile intera denominata tenureMonths e sostituire l'espressione originale con:
Il flusso di lavoro nella console inizia dalla suite di test della policy:
Aprire una policy di Automated Reasoning nella console Amazon Bedrock.
Selezionare un test non riuscito e ispezionarne i risultati.
Confermare che le premesse, l'affermazione e il risultato atteso rappresentino lo scenario previsto.
Modificare le condizioni del test se il test stesso è incompleto.
Rieseguire il test per verificare che lo scenario rivisto esprima il comportamento atteso.
Scegliere l'opzione per applicare annotazioni o perfezionare la policy.
Lasciare che Bedrock avvii un flusso di build della policy a partire dal feedback del test.
Esaminare ogni modifica proposta a regole, variabili e tipi.
Accettare le modifiche solo quando corrispondono alla policy sorgente.
Rieseguire i test salvati e gli scenari generati rispetto alla bozza rivista.
Il terzo e il quarto passaggio meritano attenzione. Un test non riuscito non dimostra sempre che la policy è errata. Il test potrebbe omettere una premessa necessaria, usare un risultato atteso impreciso oppure formulare l'affermazione in un modo che ne modifica il significato.
AWS raccomanda pertanto di ispezionare il risultato prima di applicare le annotazioni. La sua guida al perfezionamento indica agli utenti di modificare e rieseguire prima il test, quando appropriato. Se il test rivisto produce il risultato atteso, quel feedback può supportare un'annotazione mirata.
L'API espone la stessa funzionalità tramite StartAutomatedReasoningPolicyBuildWorkflow. Le riparazioni delle regole utilizzano il tipo di flusso di lavoro REFINE_POLICY. La richiesta deve includere l'intera definizione corrente della policy, non soltanto l'elemento da modificare.
Una richiesta AWS CLI semplificata ha questo aspetto:
Una richiesta di produzione sostituirebbe gli array vuoti con la definizione completa della bozza. La versione dello schema della policy deve essere 1.0, distinta dalla versione DRAFT o numerata della risorsa.
La risposta riuscita contiene due valori:
L'applicazione può interrogare il flusso di lavoro con GetAutomatedReasoningPolicyBuildWorkflow o ispezionare i flussi tramite l'operazione di elenco. Al termine dell'elaborazione, recupera la definizione della policy generata tramite GetAutomatedReasoningPolicyBuildWorkflowResultAssets.
Un comando di recupero tipico segue questo schema:
Il recupero non rende autorevole la definizione proposta. Il client dovrebbe confrontare il risultato con la bozza corrente, presentare le differenze a un revisore autorizzato e rieseguire i test pertinenti.
Dopo l'approvazione, il client può chiamare UpdateAutomatedReasoningPolicy con la definizione revisionata. Questo aggiornamento esplicito è l'equivalente API dell'accettazione delle modifiche nella console.
Il flusso di lavoro supporta operazioni più precise della sostituzione indiscriminata di un'intera policy. Le annotazioni delle variabili includono addVariable, updateVariable e deleteVariable. Le annotazioni delle regole includono addRule, updateRule, deleteRule e addRuleFromNaturalLanguage.
Le operazioni sui tipi personalizzati coprono aggiunte, aggiornamenti ed eliminazioni. Le annotazioni di feedback come updateFromRulesFeedback e updateFromScenarioFeedback consentono agli utenti di descrivere il comportamento errato di una regola o di uno scenario.
Questa gamma è utile, ma aumenta l'onere della revisione. Eliminare una variabile duplicata può migliorare la coerenza della traduzione. Eliminare una regola dall'aspetto simile può anche cancellare un'eccezione intenzionale. Ogni proposta necessita di una revisione semantica, anche quando l'espressione generata supera i controlli strutturali di Bedrock.
Il perfezionamento linguistico risolve l'ambiguità prima che raggiunga il risolutore
Il perfezionamento linguistico interviene sul confine in cui le frasi ordinarie diventano premesse e affermazioni formali, spesso la fonte meno visibile degli errori di policy.
La logica formale può valutare soltanto i concetti che le vengono forniti. Prima che avvenga tale valutazione, Bedrock deve tradurre l'input di un utente e una risposta dell'AI nelle variabili definite dalla policy.
Le descrizioni ambigue indeboliscono questa fase di traduzione. Supponiamo che una policy contenga sia tenureMonths sia monthsOfService, con descrizioni quasi identiche. La frase “Lavora qui da due anni” potrebbe essere associata a entrambe le variabili.
La regola sottostante potrebbe essere corretta, eppure un test può comunque restituire TRANSLATION_AMBIGUOUS. Questo risultato indica che il sistema ha individuato più di un'interpretazione formale plausibile. Non significa che l'affermazione sia valida o non valida.
Il perfezionamento linguistico esamina descrizioni e tipi personalizzati per rilevare queste sovrapposizioni. Propone formulazioni più chiare, concetti unificati o altre modifiche alle definizioni finalizzate a ridurre l'ambiguità. L'obiettivo non è un miglioramento stilistico. È una corrispondenza più stabile tra linguaggio naturale e schema formale.
Il flusso di lavoro nella console è più breve di una riparazione mirata delle regole:
Aprire la policy di Automated Reasoning nella console Bedrock.
Andare alla pagina Definitions.
Ispezionare gli avvisi del report di qualità.
Scegliere Resolve ambiguities.
Attendere che Bedrock analizzi le descrizioni delle variabili e le definizioni dei tipi.
Esaminare le modifiche linguistiche proposte.
Confrontare ogni proposta con il documento sorgente originale.
Accettare soltanto le modifiche che preservano il significato previsto.
Rieseguire i test contenenti formulazioni diverse e casi limite.
L'API utilizza lo stesso endpoint del flusso di build, ma il tipo di flusso di lavoro è RESOLVE_POLICY_AMBIGUITIES. La richiesta include l'intera definizione corrente:
Il client monitora quindi il flusso di lavoro e recupera la definizione proposta con il tipo di asset POLICY_DEFINITION. Può inoltre recuperare l'asset QUALITY_REPORT per comprendere quali problemi strutturali hanno motivato la raccomandazione.
L'API del flusso di build tratta il contenuto del flusso di lavoro come un'unione. In una richiesta può comparire un solo membro di contenuto supportato. I client non dovrebbero combinare il contenuto della risoluzione delle ambiguità con un altro payload del flusso di lavoro aspettandosi che entrambe le operazioni vengano eseguite insieme.
Il perfezionamento linguistico differisce anche da ITERATIVELY_REFINE_POLICY. Il flusso di lavoro iterativo utilizza un documento di origine e un feedback opzionale in linguaggio naturale per migliorare una policy esistente. È adatto quando il documento autorevole cambia o quando gli utenti vogliono orientare un perfezionamento più ampio.
Ad esempio, un manuale aziendale rivisto potrebbe ridurre una soglia di anzianità e aggiungere il congedo per lutto. Un client può fornire la definizione completa corrente, il documento aggiornato e un feedback che descriva tali modifiche.
Una richiesta semplificata utilizza questa struttura:
AWS distingue questa operazione da INGEST_CONTENT. Il perfezionamento iterativo utilizza un documento come contesto per migliorare una definizione esistente. L'ingestione estrae nuove regole da nuovo materiale e può unirle a una policy esistente.
Questa distinzione previene un comune errore di implementazione. Un nuovo capitolo del manuale dovrebbe di norma essere introdotto tramite ingestione. Un capitolo rivisto destinato a correggere la logica esistente appartiene al perfezionamento iterativo.
La correzione del linguaggio dovrebbe comunque essere testata con formulazioni multiple. Una descrizione rivista può eliminare un'ambiguità creandone un'altra. I team dovrebbero includere sinonimi, termini abbreviati, affermazioni negative e valori vicini alle soglie decisionali.
Un registro ricercabile delle clausole di origine, delle prove di test e delle revisioni accettate aiuta inoltre i revisori a ricostruire il motivo per cui una definizione è cambiata. I team di ingegneria possono organizzare tali evidenze in una base di conoscenza tecnica invece di separare le decisioni sulle policy dai documenti che le supportano.
L'Approvazione Umana È una Funzionalità, Non un Limite
La diagnosi automatica riduce il costo della manutenzione formale delle policy, ma il gate di approvazione impedisce che un errore di ottimizzazione diventi una regola organizzativa.
La verifica formale viene talvolta descritta come certezza matematica. Questa espressione richiede un confine: il motore può ragionare rigorosamente sulla policy formale che riceve. Non può garantire che la policy rappresenti perfettamente leggi, linee guida cliniche, contratti o procedure interne.
È il classico problema della specifica. Un solver può stabilire correttamente che un output segue una regola difettosa. La matematica convalida la coerenza con il modello, non la veridicità delle ipotesi alla fonte del modello.
Il perfezionamento automatico non elimina questo limite. Può rilevare che due variabili si sovrappongono, che un insieme di regole è disconnesso o che un test fallito suggerisce una condizione mancante. Non può decidere autonomamente quale interpretazione rifletta la policy legittima dell'organizzazione.
La schermata di revisione umana svolge quindi tre funzioni.
In primo luogo, crea un controllo delle modifiche. I revisori possono vedere se Bedrock propone una condizione aggiunta, una regola eliminata, una variabile rinominata o una definizione di tipo modificata.
In secondo luogo, preserva la titolarità del dominio. Un ingegnere può convalidare la sintassi e il comportamento del flusso di lavoro, mentre un legale, un clinico, un responsabile della conformità o il titolare della policy ne convalida il significato.
In terzo luogo, supporta una pista di audit. I team possono conservare il test fallito, l'annotazione proposta, la definizione accettata e i risultati dei test successivi come prova del motivo per cui una policy è cambiata.
La stessa documentazione di AWS raccomanda la revisione umana delle informazioni sulle policy generate. L'estrazione da documenti in linguaggio naturale è non deterministica, quindi esecuzioni separate possono produrre differenze nelle regole, nelle variabili e nei tipi.
Il modello operativo più sicuro utilizza almeno quattro controlli:
Richiedere l'approvazione di un titolare della policy nominato per le modifiche semantiche.
Confrontare la definizione proposta sia con la versione corrente sia con la clausola di origine.
Rieseguire l'intera suite di regressione, non solo il test che ha attivato il perfezionamento.
Pubblicare una versione numerata della policy solo dopo il completamento della revisione e dei test.
Le applicazioni dovrebbero inoltre utilizzare un token di idempotenza all'avvio dei flussi di lavoro. Il facoltativo clientRequestToken impedisce che i tentativi ripetuti creino operazioni duplicate quando viene riutilizzato lo stesso token.
Anche i limiti dei flussi di lavoro richiedono pianificazione. La documentazione AWS afferma che una policy supporta al massimo due flussi di lavoro di build, con un solo flusso in corso alla volta. Un client potrebbe dover eliminare un flusso di lavoro precedente prima di avviare un'altra build.
La crittografia e i controlli di accesso restano rilevanti perché le definizioni delle policy possono contenere logica aziendale sensibile. Bedrock supporta chiavi AWS KMS gestite dal cliente, ma l'identità chiamante e la policy della chiave devono concedere le autorizzazioni richieste per decrittografia, descrizione e chiavi dati.
Queste salvaguardie non rendono la manutenzione delle policy automatica nel senso ordinario del termine. La rendono un'automazione supervisionata. Il sistema esegue l'analisi e genera un artefatto candidato, mentre una persona controlla il cambiamento di stato.
Questo modello è più difendibile di guardrail che si modificano da soli. Se un errore in produzione indebolisse automaticamente la regola che lo ha rilevato, gli aggressori potrebbero potenzialmente influenzare la policy tramite input costruiti ad arte o feedback fuorvianti.
Un gate di revisione interrompe questo percorso. Consente inoltre ai team di respingere correzioni che aumentano i tassi di superamento dei test rendendo la policy formale meno fedele alla sua fonte.
La domanda scettica è se le organizzazioni tratteranno la revisione come un controllo reale o come una schermata di conferma di routine. Le proposte automatiche possono creare bias di automazione, soprattutto quando i revisori non hanno esperienza nella lettura di espressioni formali.
I team dovrebbero presentare le modifiche proposte in più forme: l'espressione formale, una spiegazione in linguaggio semplice, la clausola di origine e gli scenari di test interessati. Un pulsante verde di accettazione privo di questo contesto sposterebbe il collo di bottiglia anziché risolverlo.
La Pressione Si Sposta Dalla Scrittura della Logica alla Governance delle Modifiche
Amazon AWS rende più accessibile la correzione formale delle policy, ma le organizzazioni devono ora creare pratiche di revisione all'altezza della maggiore velocità di cambiamento.
Il concorrente immediato non è una singola piattaforma cloud o un fornitore di modelli. È il percorso manuale utilizzato da molti team di governance: scrivere regole a mano, ispezionare singolarmente i casi falliti e dipendere da un piccolo gruppo di specialisti per correggere il modello formale.
I guardrail basati su prompt offrono un'altra strada. Possono dire a un modello di seguire una policy o chiedere a un secondo modello di giudicare la conformità. Questi metodi sono più facili da avviare, ma le loro decisioni restano probabilistiche e possono variare in base alla formulazione o alle versioni del modello.
Automated Reasoning utilizza variabili e vincoli espliciti. Questa struttura supporta controesempi, analisi di soddisfacibilità e risultati verificabili. Richiede inoltre una specifica fedele, creando più lavoro di configurazione e manutenzione.
Il perfezionamento mira a questo costo di manutenzione. Se Bedrock trasforma in modo affidabile il feedback dei test in patch circoscritte e revisionabili, gli esperti di dominio possono dedicare meno tempo a tradurre il normale linguaggio delle policy in espressioni per solver.
Un caso cliente AWS riportato illustra il risultato previsto. Il fornitore di servizi finanziari PitCrew afferma di aver codificato 40 policy di Automated Reasoning e di utilizzarne combinazioni in tre agenti di produzione. Il suo flusso di lavoro per la conformità verifica materiali di marketing e moduli normativi rispetto a vincoli formali.
Secondo l'azienda, un processo di revisione è passato da due settimane a 30 minuti. I contenuti di marketing e social che in precedenza entravano in una coda di tre giorni sarebbero ora autorizzati in 30 secondi. Si tratta di risultati riportati dal cliente per un'implementazione specifica, non di garanzie generali sulle prestazioni.
Il caso d'uso mostra perché il perfezionamento è importante. Il materiale normativo cambia, le policy dei clienti differiscono e i casi limite emergono dopo la distribuzione. Una policy che non può essere corretta in modo efficiente diventerà obsoleta oppure accumulerà eccezioni manuali al di fuori del sistema formale.
Tuttavia, correzioni più rapide possono anche aumentare il churn delle policy. Un team potrebbe accettare frequenti correzioni locali senza verificare come ogni modifica influisca su altri gruppi di regole. Nel tempo, la definizione può diventare internamente coerente ma difficile da comprendere per le persone.
Il report di qualità può aiutare a identificare insiemi di regole disconnessi, elementi in conflitto e descrizioni ambigue. Non può sostituire la disciplina delle versioni o i test di regressione.
Le organizzazioni che valutano questa funzionalità dovrebbero misurare più del numero di suggerimenti accettati. Indicatori utili includono:
La percentuale di modifiche proposte accettate senza variazioni.
La percentuale respinta perché modifica il significato previsto.
I fallimenti di regressione introdotti da una correzione accettata.
L'ambiguità di traduzione tra formulazioni realistiche degli utenti.
Il tempo dal test fallito all'aggiornamento della policy sottoposto a revisione.
Le differenze tra le approvazioni del titolare del dominio e quelle dell'ingegnere.
Queste misure rivelano se il perfezionamento riduce il lavoro degli esperti o lo sposta semplicemente nella revisione. Espongono inoltre i casi in cui il motore propone ripetutamente modifiche plausibili ma semanticamente errate.
La funzionalità dovrebbe essere particolarmente rilevante per le applicazioni regolamentate, in cui le regole hanno fonti autorevoli e le decisioni necessitano di spiegazioni. Idoneità sanitaria, informative finanziarie, benefit per i dipendenti, copertura assicurativa e requisiti contrattuali rientrano in questo schema.
È meno adatta a preferenze generiche come “essere utile” o “scrivere testi coinvolgenti”. Questi obiettivi non dispongono delle variabili e dei vincoli precisi necessari per una valutazione formale.
Il principale compromesso resta tra capacità e governance. La correzione automatica amplia chi può partecipare allo sviluppo delle policy. Aumenta anche il numero di modifiche che i revisori potrebbero approvare senza tracciarne pienamente le conseguenze.
Cosa Osservare Dopo che Amazon AWS Automatizza il Perfezionamento
Il prossimo test sarà stabilire se le proposte di Bedrock restano circoscritte, spiegabili e fedeli quando le policy crescono oltre gli esempi controllati.
Il primo segnale è la qualità dell'accettazione nelle distribuzioni reali. AWS dovrebbe mostrare con quale frequenza gli esperti di dominio accettano le correzioni proposte senza modifiche, le rivedono o le respingono. Un'elevata accettazione accompagnata da risultati di regressione stabili sosterrebbe l'affermazione che il perfezionamento riduce il lavoro di redazione formale.
Un alto tasso di rifiuto suggerirebbe che la diagnosi è utile, ma la correzione semantica resta un lavoro da specialisti. La sola accettazione è insufficiente perché i revisori possono approvare suggerimenti errati. I risultati devono includere regressioni e rilevamenti successivi in produzione.
Il secondo segnale è costituito da evidenze provenienti da policy grandi e connesse. Gli esempi pubblicati utilizzano regole comprensibili come l'idoneità ai congedi e la valutazione del rischio ospedaliero. Le definizioni aziendali possono contenere eccezioni, riferimenti incrociati, tipi personalizzati e requisiti che interagiscono tra molte sezioni.
Una correzione che risolve uno scenario fallito può modificare le conseguenze di diverse regole distanti. I test dovrebbero rivelare se il motore identifica questo impatto più ampio e se la sua interfaccia di revisione rende visibili tali effetti.
Il terzo segnale è il modo in cui AWS amplia integrazione e governance. Aggiunte utili includerebbero diff delle policy più ricchi, ruoli di approvazione, revisori obbligatori, tracciabilità delle clausole di origine e collegamenti più chiari tra le modifiche accettate e i test interessati.
Anche la governance multi-account merita attenzione. AWS ha ampliato le salvaguardie Bedrock centralizzate, ma ha documentato limitazioni che coinvolgono i controlli Automated Reasoning in alcuni scenari di applicazione multi-account. Un supporto più esteso determinerebbe se le grandi organizzazioni possano governare queste policy in modo coerente tra i team.
Per gli sviluppatori, l'azione immediata è pratica. Iniziate con una policy circoscritta, preservate il documento autorevole e create test per approvazioni previste, rifiuti, ambiguità e condizioni limite. Attivate il perfezionamento delle regole solo dopo aver confermato che il test stesso è corretto.
Quindi esaminate ogni proposta come una decisione di policy, non come una comodità di generazione del codice. Recuperate la definizione della policy e il report di qualità, confrontateli con la bozza corrente, rieseguite l'intera suite e versionate il risultato accettato.
Per gli acquirenti enterprise, chiedete chi approva le modifiche e come vengono registrate le proposte respinte. Chiedete se i revisori vedono insieme diff formali, spiegazioni in linguaggio semplice, prove dalle fonti e impatto sulle regressioni.
Amazon AWS ha abbreviato il percorso dal fallimento alla correzione candidata. La domanda più difficile resta organizzativa: il vostro team è in grado di esaminare le modifiche formali alle policy con la stessa attenzione con cui Bedrock ora può generarle?
