La piattaforma di contract intelligence di Amazon affronta il punto cieco di RAG sui portafogli
Amazon ha pubblicato un'architettura di contract intelligence basata su otto campi estratti, creando una piattaforma di contract intelligence di Amazon per rispondere a domande che le chat basate esclusivamente su RAG gestiscono male.
Il progetto di riferimento affronta un problema persistente nelle imprese. Un chatbot riesce spesso a recuperare una clausola di pagamento da un singolo accordo. Diventa inaffidabile quando gli viene chiesto di sommare valori, confrontare date o contare documenti non firmati in centinaia di contratti.
La risposta di Amazon non è un prompt più ampio né una finestra di contesto più lunga. Separa la comprensione dei documenti dall'analisi del portafoglio. Gli agenti AI estraggono e verificano i campi, un database gestisce i calcoli e Amazon Quick offre agli utenti un'unica interfaccia per entrambi i flussi di lavoro.
Questa distinzione mette sotto pressione gli assistenti contrattuali basati esclusivamente sul recupero. Il sistema considera la retrieval-augmented generation, o RAG, come un componente anziché come il database per ogni domanda. Il risultato è un utile test di dove gli agenti enterprise trovino posto e dove i sistemi dati convenzionali restino essenziali.
Cosa ha effettivamente realizzato Amazon
Il progetto trasforma ogni contratto caricato sia in un documento ricercabile sia in un record strutturato nel database.
AWS ha pubblicato l'architettura di contract intelligence il 29 settembre 2026. Si tratta di un'implementazione di riferimento, non dell'annuncio di un servizio legale autonomo o di una distribuzione presso un cliente.
Un'applicazione React fornisce l'interfaccia utente. I PDF dei contratti entrano in un bucket di Amazon Simple Storage Service, che attiva una pipeline di elaborazione automatizzata.
Il primo agente legge ogni PDF ed estrae otto campi. AWS afferma che l'implementazione utilizza Claude Sonnet 4.6 di Anthropic e restituisce JSON strutturato con un punteggio di confidenza per ogni campo.
Un secondo agente legge in modo indipendente lo stesso documento. Secondo AWS, questo verificatore utilizza Claude Haiku 4.5 e confronta le proprie conclusioni con l'output dell'estrattore.
I due agenti operano tramite l'SDK open source Strands Agents su Amazon Bedrock AgentCore. AgentCore fornisce il runtime gestito in cui il codice degli agenti viene eseguito e scalato.
Un disaccordo non significa automaticamente che il verificatore prevalga. Per lo stato delle firme, il sistema chiama Amazon Textract come spareggio visivo. Il record verificato viene quindi inserito in Amazon Aurora PostgreSQL.
Il PDF originale segue un altro percorso. Rimane disponibile tramite una knowledge base per il recupero specifico del documento, incluse domande sulle condizioni di pagamento o su singole clausole.
Amazon Quick si colloca sopra entrambe le fonti. La sua funzionalità Quick Sight visualizza dashboard create dai record del database. La sua interfaccia conversazionale può instradare le domande verso analisi strutturate o recupero documentale.
La distinzione è importante perché queste fonti rispondono a tipi di domande diversi. La ricerca di una clausola richiede testo pertinente. Un totale di portafoglio richiede ogni record applicabile e un calcolo affidabile.
Il progetto trasmette inoltre lo stato della pipeline al browser tramite connessioni WebSocket. Gli utenti possono vedere se un file viene estratto, verificato, controllato o archiviato.
Questa visibilità è più di una rifinitura dell'interfaccia. Un flusso di lavoro enterprise diventa più semplice da ispezionare quando gli utenti possono vedere quale fase di elaborazione ha prodotto un ritardo o un disaccordo.
AWS afferma che un contratto può attraversare la pipeline in pochi secondi in condizioni tipiche. Resta un'affermazione progettuale e le prestazioni effettive dipenderanno dalla lunghezza del documento, dalla concorrenza, dalla disponibilità dei modelli e dalla configurazione regionale.
La pubblicazione segue un precedente progetto AWS di gestione contrattuale del gennaio 2026. Quella versione poneva l'accento su più agenti specialistici per attività legali, di rischio, conformità e workflow.
La nuova architettura è più circoscritta e rivelatrice. Si concentra sull'accuratezza dell'estrazione e sull'analisi del portafoglio, che mettono in luce debolezze spesso nascoste dalle dimostrazioni conversazionali.
Perché RAG non può sommare un portafoglio contrattuale
RAG seleziona passaggi pertinenti, mentre l'analisi del portafoglio richiede record completi e calcoli controllati.
La ricerca originale su RAG ha abbinato un modello linguistico a conoscenza esterna recuperata. Questo schema aiuta un modello a rispondere a domande senza inserire un'intera raccolta di fonti nel prompt.
Un sistema tipico divide i documenti in blocchi e ne crea rappresentazioni vettoriali. Quando un utente invia una domanda, la ricerca semantica recupera un insieme limitato di blocchi strettamente correlati.
Questo meccanismo funziona bene quando la risposta desiderata esiste in pochi passaggi. Una domanda sul linguaggio di risoluzione può recuperare la clausola pertinente senza rileggere ogni pagina.
Il meccanismo diventa una responsabilità quando la domanda abbraccia l'intera raccolta. Si consideri un responsabile degli acquisti che chiede il valore totale impegnato in tutti gli accordi attivi.
Il recuperatore continua a selezionare i blocchi che sembrano più pertinenti. Non garantisce che ogni accordo attivo contribuisca con un valore completo e correttamente normalizzato.
Aumentare il numero di blocchi recuperati non risolve completamente il problema. I contratti contengono etichette ripetute, emendamenti, tabelle, note a piè di pagina e date in conflitto. I passaggi pertinenti possono inoltre superare il contesto utilizzabile dal modello.
La capacità mancante non è la fluidità conversazionale. È la copertura.
AWS illustra il problema con un portafoglio ipotetico di 250 contratti. Con 10-20 pagine ciascuno, quel portafoglio può contenere fino a 5.000 pagine.
Una persona può alla fine ispezionare ogni documento e mantenere un foglio di calcolo. Tuttavia, ogni nuovo accordo o emendamento può rendere obsoleto il foglio.
Un assistente RAG può rispondere più rapidamente, ma continuare a omettere record al di fuori della sua finestra di recupero. La risposta può sembrare completa anche quando il calcolo copre solo un sottoinsieme.
Questo è il principale confronto alla base della piattaforma di contract intelligence di Amazon: chat basata esclusivamente su RAG contro estrazione seguita da query al database.
Con l'approccio di estrazione, ogni contratto passa attraverso lo stesso schema. Valori, date, controparti, stati delle firme e altri campi selezionati diventano righe e colonne.
Un database può quindi filtrare i record attivi, raggrupparli per fornitore e calcolare i totali. Può anche restituire i record alla base del risultato per ulteriori ispezioni.
Questa architettura non rende obsoleto RAG. Assegna a RAG un compito più circoscritto, in linea con i suoi punti di forza.
Il recupero documentale rimane prezioso per le domande che resistono alla normalizzazione. Il linguaggio sui pagamenti, le clausole di responsabilità, le eccezioni e gli obblighi insoliti richiedono spesso il testo circostante.
L'analisi strutturata serve un livello diverso. Supporta domande quali quanti accordi siano scaduti, quali contratti non firmati abbiano il valore più elevato o quali rinnovi si avvicinino a una data selezionata.
I due percorsi possono completarsi a vicenda. Una query strutturata identifica i contratti che richiedono attenzione, mentre il recupero riporta le clausole di supporto.
Questa divisione produce anche un modello di errore più chiaro. Gli errori di recupero influenzano una risposta documentale. Gli errori di estrazione possono influenzare le dashboard e ogni aggregato costruito sul campo memorizzato.
Ciò rende la pipeline di acquisizione più importante dell'interfaccia chat. Il livello conversazionale è affidabile solo quanto i record e le fonti di recupero che lo sostengono.
Come la piattaforma di contract intelligence di Amazon modifica il percorso dei dati
L'architettura sposta il lavoro più difficile dal momento della domanda al momento dell'acquisizione.
Un assistente basato esclusivamente su RAG rimanda l'interpretazione fino a quando qualcuno non pone una domanda. La piattaforma di contract intelligence di Amazon interpreta i campi contrattuali selezionati quando ogni documento entra nel sistema.
Questo cambiamento crea un livello analitico riutilizzabile. Una volta che una data di rinnovo è stata estratta, verificata e archiviata, più dashboard e domande possono utilizzare lo stesso valore normalizzato.
Il primo passaggio è l'acquisizione del documento tramite Amazon S3. Un caricamento avvia il flusso di elaborazione senza richiedere a un analista di aprire manualmente il file.
L'agente di estrazione legge quindi il PDF in modo nativo, secondo AWS. Produce gli otto campi previsti e allega punteggi di confidenza che i componenti a valle possono ispezionare.
I punteggi di confidenza sono segnali, non garanzie. Possono aiutare a dare priorità al lavoro di revisione, ma non stabiliscono che un valore estratto corrisponda al significato legale di una clausola.
Il verificatore indipendente introduce una seconda lettura. L'uso di un diverso membro della famiglia di modelli mira a ridurre gli errori correlati derivanti dalla ripetizione dello stesso processo di estrazione.
L'idea ricorda la revisione da parte di due persone, ma l'analogia ha dei limiti. Due modelli dello stesso fornitore possono comunque condividere schemi di addestramento, punti ciechi e debolezze nella gestione dei documenti.
AWS ha valutato combinazioni di estrattore e verificatore con 20 contratti. Il team ha etichettato manualmente otto campi in ciascun contratto, producendo 160 valori di riferimento.
Questa valutazione ha suggerito che l'estrattore fosse più importante del verificatore. Secondo gli autori, un modello di estrazione più capace ha preservato i risultati quando abbinato a un verificatore più leggero.
AWS afferma inoltre che i modelli più potenti non hanno sempre fornito un miglioramento significativo su quel dataset. L'azienda consiglia di testare i modelli disponibili rispetto ai contratti e ai criteri di accettazione di ciascuna organizzazione.
Questa precisazione è importante. Venti contratti costituiscono un test indicativo, non una prova che la combinazione selezionata si generalizzerà a settori, lingue o stili di redazione diversi.
Dopo la verifica, il database diventa il sistema per le domande aggregate. Amazon Quick si collega ad Aurora PostgreSQL e può interrogare dati in tempo reale anziché attendere un'esportazione separata.
Amazon Quick si collega anche alla knowledge base che contiene i documenti sorgente. Il suo agente chat può quindi supportare domande strutturate e ricerche di singoli documenti all'interno di un'unica interfaccia.
Questo instradamento è il meccanismo architetturale alla base del funzionamento della contract intelligence di Amazon. Il modello non esegue ogni calcolo leggendo la prosa contrattuale durante ciascuna conversazione.
Per una richiesta aggregata, la fonte strutturata fornisce record filtrati e calcoli. Per una richiesta specifica di un documento, la knowledge base recupera il testo contrattuale pertinente.
AWS presenta output di esempio basati su un portafoglio campione contenente 20 contratti. Gli esempi includono il valore del portafoglio, i totali dei contratti scaduti e il conteggio degli accordi firmati e non firmati.
Questi numeri illustrano l'interfaccia. Non sono risultati operativi provenienti da un portafoglio clienti divulgato e non devono essere letti come prove di prestazione.
Le dashboard integrate offrono un altro modo per ispezionare gli stessi dati. Gli utenti possono visualizzare i totali del portafoglio, lo stato delle firme, i risultati dell'estrazione e i confronti di confidenza senza uscire dall'applicazione.
Questa base condivisa può ridurre le discrepanze tra gli output di dashboard e chat. Entrambe le interfacce possono fare riferimento agli stessi record verificati nel database per le domande analitiche.
Il progetto conserva inoltre l'accesso al materiale sorgente. Gli analisti non devono trattare un valore del database come l'ultima parola quando una decisione contrattuale richiede la lettura della clausola.
Questo schema ibrido va oltre i contratti. Sinistri assicurativi, dichiarazioni di conformità, contratti di locazione e registri di onboarding possono tutti combinare campi ripetibili con linguaggio specifico del documento.
Corrisponde inoltre a un più ampio principio di knowledge blending. I fatti strutturati e il contesto della fonte servono scopi diversi, e i sistemi utili necessitano di un ponte governato tra i due.
La verifica conta più di un’altra chiamata al modello
L’aspetto più istruttivo del design è il suo rifiuto di lasciare che i modelli linguistici risolvano ogni controversia.
Durante i test, AWS ha rilevato che il verificatore talvolta classificava come firmati blocchi di firma vuoti. In alcuni casi di falsi positivi, la confidenza riportata raggiungeva tra il 95 e il 100 per cento.
Il modello riconosceva parole e layout associati alla firma. Ha quindi trattato la presenza di un campo firma come prova che qualcuno avesse firmato.
Questo errore evidenzia un problema ricorrente dell’AI generativa. Un punteggio di confidenza può descrivere la certezza interna del modello senza dimostrare che la conclusione sottostante sia corretta.
AWS ha risposto aggiungendo Textract soltanto quando i due modelli non erano d’accordo sullo stato della firma. Textract esamina caratteristiche visive per rilevare firme manoscritte o digitali.
La scelta crea un controllo in tre parti. Un modello esegue l’estrazione, un altro la verifica e un servizio specializzato di computer vision risolve una classe definita di disaccordi.
È una soluzione più adatta che chiedere a un terzo modello linguistico di votare. Un terzo modello potrebbe riprodurre la stessa confusione semantica tra una riga per la firma e una firma effettiva.
Questo schema limita inoltre il controllo specializzato ai casi contestati. Preserva il flusso di lavoro principale applicando un metodo tecnico diverso dove i modelli mostrano incertezza.
Tuttavia, Textract è uno spareggio per la presenza della firma, non un arbitro per ogni campo. Valori contrattuali, regole di rinnovo, date e identità delle parti possono creare ambiguità differenti.
Un emendamento potrebbe sostituire un valore precedente. Una clausola di rinnovo automatico può richiedere un’interpretazione contestuale. Una firma può esistere mentre l’accordo rimane incompleto per un’altra ragione.
Questi casi richiedono regole esplicite di escalation. Il post di AWS afferma che i disaccordi irrisolti dovrebbero passare a un revisore umano quando i servizi deterministici non riescono a risolverli.
Questo percorso umano è centrale per un’adozione responsabile. Determina se l’automazione riduce il lavoro di routine o nasconde semplicemente record incerti all’interno di un database.
Il sistema dovrebbe conservare ogni valore estratto, la sua posizione nella fonte, gli output di entrambi i modelli e la risoluzione finale. Altrimenti, i revisori non possono ricostruire perché una dashboard includa una determinata cifra.
Le organizzazioni necessitano inoltre di soglie specifiche per campo. Un nome di contatto errato e una data di cessazione errata non comportano lo stesso rischio operativo.
Il framework AI del NIST sottolinea test, valutazione, verifica e validazione per i sistemi di AI. I flussi di lavoro sui contratti richiedono tali pratiche a livello di singolo campo dati.
I team dovrebbero misurare precisione, richiamo e prestazioni di corrispondenza esatta per campo. Dovrebbero inoltre monitorare i tassi di disaccordo, le correzioni dei revisori e gli errori scoperti dopo l’approvazione.
L’accuratezza dovrebbe essere segmentata per tipo di documento. PDF nativi, pagine scansionate, tabelle, emendamenti, annotazioni manoscritte e accordi multilingue possono comportarsi diversamente.
La valutazione AWS su 20 contratti offre una metodologia iniziale. Non fornisce però una diversità sufficiente per stabilire l’affidabilità in produzione per il portafoglio di un’altra organizzazione.
Un pilota utile dovrebbe campionare i documenti che generano il maggior rischio. Ciò include modelli insoliti e file di bassa qualità, non solo accordi puliti basati su un modulo standard.
La verifica a doppio modello del design rimane preziosa perché rende osservabile il disaccordo. Crea un evento misurabile che può attivare controlli deterministici o una revisione umana.
Tuttavia, l’accordo tra i modelli non può essere trattato come verità assoluta. Due agenti possono produrre lo stesso valore errato, soprattutto quando il testo sorgente è ambiguo.
Il controllo essenziale è la tracciabilità. Ogni valore strutturato dovrebbe riportare il revisore alla pagina, alla clausola e alla decisione di estrazione che lo hanno prodotto.
Accuratezza, accesso ed economia restano da dimostrare
L’architettura di riferimento definisce un meccanismo credibile, ma non dimostra la prontezza alla produzione per ogni portafoglio contrattuale.
La prima incertezza riguarda la scala della valutazione. AWS ha utilizzato 20 contratti e 160 valori etichettati per confrontare combinazioni di modelli.
Quel campione può rivelare differenze evidenti tra le configurazioni. Non può rappresentare l’intera gamma di formattazione, redazione, scansione, lingua e schemi di emendamento presenti negli accordi aziendali.
La seconda incertezza riguarda la copertura dello schema. Otto campi possono supportare dashboard utili, ma le operazioni contrattuali dipendono spesso da obblighi più complessi e date condizionali.
Una data di rinnovo può dipendere da periodi di preavviso. Un valore può combinare tariffe impegnate, addebiti a consumo, crediti o aumenti indicizzati.
Appiattire questi termini in un unico record può creare un’illusione di certezza. Lo schema deve preservare le qualificazioni quando un campo non può essere rappresentato come un semplice numero o una data.
La terza incertezza riguarda il cambiamento dei modelli. AWS osserva che la disponibilità dei modelli evolve e consiglia agli sviluppatori di ripetere i test del sistema prima di affidarsi a nuove opzioni.
Un modello sostitutivo può modificare il comportamento di estrazione anche se l’applicazione circostante rimane invariata. I team di produzione necessitano quindi di set di valutazione fissi e gate di rilascio.
La quarta incertezza è l’autorizzazione. I contratti possono contenere prezzi riservati, informazioni sui dipendenti, obblighi di sicurezza e condizioni strategiche relative ai fornitori.
AWS afferma che AgentCore supporta l’isolamento delle sessioni, mentre i controlli delle policy possono risiedere al di fuori del codice dell’agente. La documentazione di AgentCore descrive ambienti di esecuzione separati per le sessioni utente.
Tuttavia, l’isolamento dell’infrastruttura non crea automaticamente autorizzazioni aziendali corrette. La documentazione AWS afferma che i backend client devono mantenere la relazione tra utenti e identificatori di sessione.
Gli sviluppatori devono inoltre applicare i controlli di accesso ai livelli di documento, database, dashboard e strumenti dell’agente. Un’interfaccia chat non dovrebbe rivelare un record che lo stesso utente non può aprire altrove.
La quinta incertezza riguarda l’economia operativa. Il post di AWS fornisce un modello di costo esemplificativo, ma le condizioni commerciali cambiano e i carichi di lavoro dei portafogli differiscono.
I costi di elaborazione dipendono dal numero di pagine, dalle chiamate ai modelli, dai tentativi, dallo storage, dalla capacità del database, dalla concorrenza e dalla frequenza delle query degli utenti. La revisione umana può diventare la variabile più grande.
Un caso aziendale credibile dovrebbe misurare il costo per record accettato, non il costo per invocazione del modello. Un’estrazione economica che genera un ampio lavoro di revisione non è economicamente economica.
Il panorama competitivo offre inoltre diverse strade di implementazione. Il modello di estrazione contratti di Microsoft restituisce campi strutturati dai contratti tramite Document Intelligence.
Anche Document AI di Google converte documenti non strutturati in dati strutturati per l’elaborazione a valle.
Questi prodotti differiscono per schemi, personalizzazione, orchestrazione, analisi e integrazione cloud. Gli acquirenti dovrebbero confrontare l’intero ciclo di controllo anziché un singolo benchmark di estrazione.
La differenziazione di Amazon in questo design è il collegamento tra agenti, verifica, database relazionale, analisi incorporata e domande e risposte sui documenti.
Questa integrazione può attirare organizzazioni che operano già su AWS. Può inoltre aumentare l’impegno architetturale tra storage, modelli, database, analisi e controlli di identità.
I team dovrebbero testare la portabilità prima della produzione. I record estratti e i dati di provenienza dovrebbero utilizzare schemi documentati che rimangano accessibili al di fuori di una singola interfaccia conversazionale.
Dovrebbero anche definire la responsabilità dei fallimenti. I team di procurement, operazioni legali, data engineering e sicurezza possono ciascuno presumere che un altro gruppo convalidi l’output.
Un flusso di lavoro necessita di un unico responsabile per modifiche allo schema, soglie di valutazione, code delle eccezioni e revisioni degli accessi. Senza questa responsabilità, il sistema può automatizzare l’incoerenza.
La lezione più ampia è che la contract intelligence è un progetto di governance dei dati con un livello di ingestione AI. Trattarla come un’implementazione di chatbot sottovaluta il lavoro.
Cosa dovrebbero osservare gli acquirenti
Tre segnali mostreranno se questa architettura diventerà un sistema operativo affidabile per i dati contrattuali o resterà una convincente demo di riferimento.
Il primo segnale è costituito da prove di valutazione su set di contratti più ampi e diversificati. Gli acquirenti necessitano di risultati a livello di campo su scansioni, emendamenti, tabelle, lingue e schemi di redazione non comuni.
La sola accuratezza pubblicata non sarà sufficiente. Prove utili dovrebbero rendere noti la composizione del dataset, le categorie di errore, le policy di revisione e la frequenza con cui entrambi i modelli hanno concordato su un valore errato.
Prove migliori rafforzerebbero l’affermazione centrale di Amazon secondo cui la verifica indipendente migliora l’affidabilità. Errori correlati persistenti indebolirebbero l’argomentazione a favore del design a doppio modello.
Il secondo segnale è la gestione delle eccezioni di livello produttivo. La piattaforma necessita di code di revisione configurabili, citazioni delle fonti, cronologia delle approvazioni e percorsi chiari per i disaccordi irrisolti.
Amazon Quick include funzionalità human-in-the-loop, ma le organizzazioni devono mostrare come tali controlli si inseriscano nelle operazioni contrattuali quotidiane. I revisori necessitano di contesto, non di un altro punteggio di confidenza inspiegato.
Un flusso di lavoro maturo dovrebbe consentire a qualcuno di correggere un campo, documentarne la ragione e aggiornare le analisi a valle senza perdere l’output originale.
Le implementazioni di successo separeranno inoltre l’automazione a basso rischio dalle decisioni ad alto rischio. I conteggi del portafoglio possono tollerare controlli diversi rispetto agli avvisi di cessazione o agli impegni finanziari.
Il terzo segnale è l’adozione oltre i carichi di lavoro dimostrativi. Occorre osservare implementazioni clienti divulgate che colleghino la qualità dell’estrazione a risultati operativi misurabili.
Gli indicatori rilevanti includono il tempo di revisione, i tassi di correzione, la frequenza dei record obsoleti e la percentuale di contratti elaborati senza escalation. Queste misure contano più della velocità di risposta del chatbot.
Anche la concorrenza modellerà l’adozione. Microsoft e Google supportano già l’estrazione strutturata di documenti, mentre le piattaforme di contract lifecycle offrono flussi di lavoro specifici per il dominio.
Amazon deve dimostrare che Quick e AgentCore riducono il lavoro di integrazione senza limitare la flessibilità dello schema o la governance. I concorrenti devono dimostrare percorsi altrettanto coerenti dai documenti alle analisi verificate del portafoglio.
La piattaforma di contract intelligence di Amazon presenta il suo argomento più forte attraverso l’architettura, non la novità del modello. Riconosce che recupero, estrazione, verifica e calcolo sono lavori distinti.
Questo riconoscimento offre ai team aziendali una regola decisionale pratica. Mantenete RAG per individuare e spiegare i passaggi della fonte. Utilizzate record strutturati per contare, ordinare, confrontare e totalizzare.
Poi collocate i controlli di revisione dove una risposta errata modificherebbe una decisione legale o finanziaria. Nessun punteggio di confidenza del modello dovrebbe aggirare automaticamente tale giudizio.
Per i team che valutano l’AI contrattuale, il passo successivo è un pilota rappresentativo. Selezionate documenti difficili, etichettate i campi richiesti, definite soglie di accettazione e misurate lo sforzo dei revisori.
Chiedetevi se ogni risposta può essere ricondotta alla sua fonte. Testate le autorizzazioni tra utenti, contratti, dashboard e sessioni chat. Ricalcolate gli aggregati dopo correzioni ed emendamenti.
Soprattutto, confrontate l’architettura ibrida con il processo che sostituisce. Produce dati di portafoglio più aggiornati, con meno errori nascosti e una traccia di audit difendibile?
Questo è il test che conta. Una piattaforma di contract intelligence Amazon ha successo quando rende l’intero portafoglio interrogabile in modo affidabile, non semplicemente quando un contratto produce una risposta convincente.
