--- schema_version: "1" id: 389ef5603312b7f3ad5574a26cbe93de55767c15adaa8e09ed74aa5fc15fe9c7 title: AI documento Data 360 collection: architect version: current locale: it-it portal_url: https://docs.salesforce.com/architect/current/it-it/fundamentals/guides/data360-document-ai.md canonical_url: https://architect.salesforce.com/docs/architect/it-it/fundamentals/guide/data360-document-ai.html source_site: architect.salesforce.com content_type: documentation content_hash: dbbe9d4dbd96a37b11281a27e88acfe4428491c801587488de5ac860026a34b6 products: - Nozioni di base - Architect Site Content Repo updated_at: 2026-07-01T00:00:00Z --- ## Panoramica Le aziende gestiscono un'ampia gamma di tipi di documenti, tra cui fatture, ordini di acquisto, contratti legali e manuali tecnici. L'elaborazione manuale è lenta, soggetta a errori e consuma circa il 15-25% del tempo dei dipendenti. Gli approcci di automazione precedenti (ad esempio, _Robotic Process Automation (RPA)_, _Optical Character Recognition (_OCR) e strumenti di flusso di lavoro) hanno ridotto parte del carico, ma hanno prodotto pipeline rigide, elevati costi di manutenzione e adozione in silo tra i singoli team aziendali. I documenti contengono un contesto strutturale RTF (ad esempio, gerarchie di tabelle, relazioni tra campi spaziali e sezioni con riferimenti incrociati) che l'elaborazione di testo piatto non può mantenere. La rimozione di un documento dal testo normale elimina il contesto aziendale che rende l'estrazione precisa e utile, degradando la qualità dell'analisi a valle, dell'inferenza dell'_intelligenza artificiale_ e dell'automazione dei processi. Per essere efficaci, i sistemi di _elaborazione intelligente dei_ documenti devono classificare i documenti in base al tipo, estrarre i dati strutturati in modo preciso dai layout variabili e fornire tali dati in un formato governato e interrogabile ai sistemi a valle. Gli IDP devono inoltre gestire la variabilità dei documenti su larga scala senza richiedere la configurazione per modello per ogni nuovo formato di documento e devono essere centralizzati e accessibili tra le unità operative. Questa sfida è aggravata dall'enorme volume del problema chiave: i dati non strutturati rappresentano circa l'80% di tutti i dati aziendali e la maggior parte si accumula sotto forma di documenti in file system, cloud storage e archivi di contenuti che non sono alla portata dei sistemi _CRM (Customer Relationship Management)_, degli agenti AI e delle piattaforme di analisi. _Data 360 Document AI_ è la funzionalità di elaborazione documenti di Salesforce all'interno di _Data 360_, progettata per risolvere questa lacuna. Estrae, classifica e analizza il contenuto di documenti non strutturati e semi-strutturati utilizzando _modelli LLM (Large Language Models)_, _Riconoscimento ottico caratteri_, _elaborazione linguaggio naturale_ e _apprendimento automatico_. L'output è costituito da dati strutturati, governati e interrogabili che si integrano nella pipeline di _Data 360_ a cui gli agenti _Agenteforce_, gli strumenti di analisi e i flussi di lavoro di automazione possono accedere tramite interfacce standard senza richiedere livelli di estrazione o trasformazione personalizzati. ## Perché l'intelligenza artificiale dei documenti è importante? Le piattaforme dati aziendali elaborano dati strutturati e tabulari. Tuttavia, la maggior parte dei dati aziendali arriva sotto forma di documenti e rimane inaccessibile agli agenti CRM, ERP, AI e alle opportunità di analisi finché qualcuno non li estrae manualmente. Si tratta di una lacuna architettonica, non di un problema di flusso di lavoro. ### Limitazioni dell'estrazione basata su regole Gli approcci precedenti combinavano reimpaginazione manuale, OCR basato su regole e script RPA. Questi metodi funzionavano su piccola scala, ma non erano in grado di gestire il volume, la varietà e la velocità dei tipi di documenti generati dalle aziende moderne. Gli strumenti basati su regole richiedono modelli espliciti per variante di layout. Qualsiasi modifica del formato interrompe l'estrazione e richiede uno sviluppatore, un nuovo modello e un ciclo di distribuzione. Su larga scala, ciò produce soluzioni fragili senza governance centralizzata, schema condiviso e percorso per la preparazione all'intelligenza artificiale. Pipeline di estrazione incoerenti si propagano a valle. In altre parole, gli analytics ereditano le incoerenze dei dati, i modelli di intelligenza artificiale producono output inaffidabili e contenuti regolamentati come _Personal Health Information (PHI)_ e _Personaly Identifiable Information (PII)_ non dispongono di una governance sistematica. ### Elaborazione documenti nativa AI Gli LLM estraggono i campi senza modelli espliciti. Un'unica configurazione dello schema regola l'estrazione tra le varianti di layout, le lingue e i formati, adattandosi al documento anziché richiedere che il documento sia conforme a una struttura fissa. In questo modo l'elaborazione dei documenti passa da un'operazione di manutenzione pesante e in silo a una funzionalità gestita e centralizzata. ![Panoramica dell'intelligenza artificiale dei documenti di Data 360 che mostra come le pipeline batch e transazionali trasformano i documenti non strutturati in dati governati e interrogabili](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-overview.png) _Data 360 Document AI_ rende operativa l'elaborazione dei documenti all'interno della piattaforma _Data 360_ tramite due opportunità in corso di realizzazione. - La pipeline _batch_ instrada i dati estratti attraverso l'inserimento, la risoluzione dell'identità, gli approfondimenti calcolati, le attivazioni, gli analytics e l'attivazione Agentforce. - La pipeline di _elaborazione transazionale_ espone un'API REST che restituisce _JSON_ strutturato in modo sincrono, che consente agli architetti di instradare i dati derivati da documenti a _SObject_ Salesforce, alla pipeline _Data Lake Object_/_Data Model Object (DLO/DMO)_ o a database e magazzini esterni senza sovraccarico di impostazione batch. In entrambi i casi, i dati estratti entrano in un modello governato basato su schema anziché in un insieme frammentato di strumenti puntuali. ## Prodotto nell'ambito [Data 360 Document AI](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) è la funzionalità nativa di _elaborazione documenti intelligente_ di Salesforce all'interno della piattaforma _Data 360_. Converte il contenuto di documenti non strutturati e semistrutturati in dati governati e interrogabili che partecipano completamente all'intero ciclo di vita di _Data 360_. ## Che cos'è Data 360 Document AI? [Data 360 Document AI](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) è la funzionalità nativa di _elaborazione documenti intelligente_ di Salesforce all'interno di _Data 360_. Inserisce documenti non strutturati e semistrutturati, estrae dati strutturati utilizzando una configurazione schema dichiarativa e li consegna alle opportunità in corso di realizzazione _di Data 360_ per l'armonizzazione, la risoluzione dell'identità, l'analisi e l'attivazione Agentforce. L'intelligenza artificiale dei documenti di Data 360 supporta due modalità di elaborazione: - **Elaborazione batch in blocco:** Elabora insiemi di documenti di grandi dimensioni definiti negli _oggetti modello di_ dati basati sugli eventi. - **Elaborazione transazionale:** Elabora un singolo documento tramite l'API REST e restituisce un payload _JSON_ strutturato in modo sincrono. Gli architetti possono quindi instradare il payload alle pipeline _DLO/DMO Data 360_, _agli SObject_ Salesforce o ai database e magazzini esterni tramite pipeline _MuleSoft_, chiamate _Apex_ o _Einstein Trust Layer (ETL)_. Il livello di destinazione è una decisione architetturale determinata dai requisiti di latenza, governance e residenza dei dati. L'intelligenza artificiale dei documenti attualmente supporta file PDF, file di immagine (JPEG, PNG) e documenti scritti a mano. ## Componenti principali _Data 360 Document AI_ riunisce quattro tecnologie di elaborazione in un'unica pipeline gestita. Ogni componente gestisce una fase distinta del ciclo di vita da documento a dati: - **Riconoscimento ottico dei caratteri (OCR):** Converte le immagini acquisite, il contenuto scritto a mano e i PDF basati su immagini in testo leggibile dal computer prima dell'elaborazione LLM. Per un'estrazione affidabile si consiglia un minimo di 150 DPI. - **Modelli di lingua grandi (LLM):** Instradare l'estrazione attraverso il gateway _Einstein_ LLM utilizzando il modello scelto dall'utente. LLM riceve l'output OCR insieme alla configurazione dello schema _JSON_ e restituisce un payload di estrazione strutturato. _Gemini_ e altri modelli sono in fase di pianificazione per la futura implementazione. - **Elaborazione del linguaggio naturale (NLP):** Esegue la comprensione contestuale, il riconoscimento delle entità, l'analisi della data e l'estrazione semantica dei campi direttamente all'interno del LLM tramite l'ingegneria dei prompt strutturati: il prompt definito dallo schema e l'output OCR fungono da unici input. Tutte le interazioni LLM vengono instradate attraverso l'ETL, che impone la conservazione zero dei dati con i provider del modello e maschera le _informazioni personali_ negli input basati su testo prima che raggiungano il modello. Non viene utilizzato un motore NLP separato. - **Elaborazione multimodale:** Elabora le immagini incorporate all'interno dei PDF come input di estrazione separati, il che consente all'LLM di estrarre i dati da diagrammi, tabelle di rendering delle immagini e pagine a contenuto misto che l'OCR da solo non può analizzare. Oltre alle quattro tecnologie di elaborazione, _Document AI_ gestisce anche: - **Strato Einstein Trust:** Instrada tutte le interazioni LLM attraverso l'ETL, che impone la conservazione zero dei dati con i provider di modelli e maschera le _informazioni personali_ prima che gli input raggiungano l'ETL, ad eccezione dei dati multimodali (ad esempio, i documenti allegati elaborati tramite _Document AI_) in cui il mascheramento delle informazioni personali non è attualmente supportato e i dati vengono inviati così come sono ai modelli esterni. L'ETL governa solo il percorso di interazione LLM. I dati estratti scritti in _Oggetti data lake (DLO)_ sono memorizzati così come sono; il mascheramento a livello di campo a riposo deve essere gestito tramite controlli di governance dei dati a valle. - **Limite delle dimensioni dei file:** _Document AI_ elabora file fino a 10 MB per richiesta. I limiti di lunghezza del contesto LLM possono limitare ulteriormente l'elaborazione di documenti densi e multipagina all'interno di questo confine. ## Principi architettonici chiave Gli architetti Enterprise che distribuiscono _Data 360 Document AI_ devono applicare questi principi prima di impegnarsi in una progettazione dell'implementazione. - **Selezionare la pipeline prima di progettare lo schema.** Le pipeline di elaborazione _batch_ e _transazionale si_ differenziano per modello di inserimento, binding dello schema, flessibilità del target e latenza. È importante confermare quali opportunità in corso di realizzazione richiede ogni caso d'uso prima di definire lo schema, poiché l'adattamento successivo aggiunge una rielaborazione evitabile. - **Progettare schemi a livello di tipo di documento.** L'utilizzo di un unico schema ben elaborato per tipo di documento è più manutenibile rispetto all'utilizzo di configurazioni per caso d'uso ed è anche la leva più grande per la qualità dell'estrazione. Per eseguire correttamente questa operazione è necessario utilizzare una serie di documenti diversificata, inclusi i casi limite, anziché progettare da un singolo esempio. Utilizzare i prompt in modo iterativo a livello di _campo_, _tabella_ e _schema_ per trovare lacune e quindi testarli e perfezionarli in base a più esempi di documenti prima di finalizzare. Tenere presente che uno schema che funziona bene su un documento può non essere sufficiente su altri, quindi l'ampiezza e l'iterazione sono essenziali. La flessibilità dello schema, inclusa la rimozione delle colonne che non vengono estratte in modo affidabile tra i vari tipi di documento, è altrettanto importante. Mantenere i campi che introducono rumore o incoerenza compromette la qualità complessiva dell'estrazione, quindi è importante considerare la rimozione delle colonne come una decisione di progettazione di prima classe. - **Scegliere il livello di destinazione corretto per gruppo di campi.** I campi che determinano i flussi di lavoro o le approvazioni CRM vengono scritti in _SObjects_. I campi che arricchiscono il profilo unificato o l'analisi dei feed appartengono alla pipeline _DLO/DMO_. I campi che servono sistemi esterni appartengono al livello _RDBMS_. Tenere presente che un singolo schema può estendersi contemporaneamente a più livelli. - **Applicare la governance prima di elaborare i contenuti regolamentati.** I dati regolamentati necessitano di protezione a ogni livello. Ecco perché è importante configurare il mascheramento _delle informazioni personali_, i tag di classificazione dei dati e l'_ABAC (Attribute-Based Access Control_) dopo che i dati estratti sono stati memorizzati nei _DLO (Data Lake Objects_) di output Ciò offre un'applicazione più precisa e un accesso sensibile al contesto basato sulla classificazione dei dati, sul ruolo utente e sul contesto organizzativo. La _governance_ è suddivisa in due percorsi: l'_ELT_ governa l'interazione LLM, mentre i dati estratti archiviati nei DLO devono essere governati separatamente, direttamente a livello di DLO e database, tramite le configurazioni dello _spazio dati_, gli _insiemi di autorizzazioni_ e le policy _ABAC_. Questi controlli devono mantenere la coerenza a livello di memoria, non solo a livello di applicazione, in modo che le restrizioni di accesso rimangano intatte indipendentemente dal modo in cui si accede ai dati dopo l'inserimento. Tenere presente che eventuali lacune in qualsiasi livello possono esporre i dati regolamentati a valle anche quando altri sono configurati correttamente. - **Progettare per le modalità di errore prima della produzione.** Risolvere la gestione dei campi nulli, le soglie di qualità OCR, la pre-convalida delle dimensioni del file, l'overflow del contesto LLM, l'impotenza di scrittura RDBMS e i limiti del budget di credito prima della prima esecuzione batch di produzione. Non si tratta di casi limite, ma di superfici di errore prevedibili che devono essere gestite in modo esplicito nella progettazione delle opportunità in corso di realizzazione e non rilevate in fase di esecuzione. - **Trattare i punteggi di confidenza come un segnale di calcolo del percorso di prima classe, non come un ripensamento diagnostico.** I risultati dell'estrazione contengono valori di confidenza a livello di campo derivati dalle probabilità di registrazione (logprobs) dell'output del modello sottostante. Per ogni campo, tabella o colonna estratta, il punteggio riflette la certezza a livello di token del valore estratto del modello. Ciò rende i punteggi di confidenza un segnale basato su dati statistici sufficientemente affidabile da fungere da porta principale per le soglie di inoltro al livello superiore _di Human-in-the-Loop (HITL)_. Utilizzare i punteggi di confidenza per identificare sistematicamente le estrazioni di bassa qualità e avviare controlli HITL per i valori dei campi con bassa confidenza, corrispondenze ambigue dello schema o errori ripetuti delle opportunità in corso di realizzazione anziché affidarsi all'euristica o a controlli manuali a campione. Quando il ripristino automatico non è possibile, il calcolo del punteggio di confidenza basato su HITL garantisce che il giudizio umano venga applicato esattamente dove necessario. - **Progettare i percorsi di attivazione in parallelo alla progettazione dello schema.** Il valore di _Document AI_ deriva dalla possibilità di attivare i dati estratti all'interno dei flussi di lavoro e degli agenti Salesforce. Consente di progettare _azioni_ Agentforce, _flussi_ e _approfondimenti calcolati_ insieme alla progettazione dello schema di estrazione, non dopo. ## Architettura: Pipeline AI documento Data 360 _Document AI_ opera all'interno di due opportunità in corso di realizzazione: - Una pipeline _batch_ per l'elaborazione a volume elevato, supportata da UDMO - Una pipeline di _elaborazione_ _transazionale_ per l'estrazione in tempo reale basata sull'API Entrambe le opportunità in corso di realizzazione condividono lo stesso contratto di configurazione dello schema e la stessa governance ETL, ma differiscono per il modo in cui i documenti entrano nel sistema e dove finiscono i dati estratti. Vediamo più nel dettaglio ogni pipeline. ### Pipeline di elaborazione batch La pipeline _batch_ elabora gli insiemi di documenti ricorrenti definiti da un UDMO. Si adatta ai casi d'uso pianificati o basati sugli eventi in cui i documenti vengono inseriti dall'archiviazione aziendale, quindi passano attraverso l'estrazione dei documenti e vengono consegnati alla pipeline _DLO/DMO Data 360_ per l'armonizzazione, la risoluzione dell'identità e l'attivazione. **Scenario reale** Ogni giorno, un operatore assicurativo riceve migliaia di documenti relativi alle richieste mediche dai portali operatori che vengono caricati come PDF in _Amazon S3_. L'UDMO definisce l'insieme di documenti nell'ambito e invia tutti i PDF delle richieste al bucket `/claims/incoming/` entro 24 ore. ![Elaborazione in batch delle richieste mediche di un operatore assicurativo, dall'inserimento all'armonizzazione, alla risoluzione dell'identità e all'attivazione Agentforce](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-batch-processing.png) #### Fase 1: Inserisci I documenti vengono inseriti in _Data 360_ dai sistemi di origine aziendali senza duplicazione fisica. Le fonti supportate includono _Amazon S3_, _Google Cloud Storage_, oggetti di file Salesforce CRM, pipeline _orchestrate da MuleSoft_ e caricamenti API diretti. Nelle distribuzioni _Headless 360_, i documenti vengono inseriti tramite connettori di archiviazione cloud o l'_API di inserimento_, che ignora il livello CRM. Il server _Model Context Protocol (MCP)_ espone l'inserimento come strumento di chiamata per gli agenti AI esterni e i client LLM. Al momento dell'inserimento, i documenti non strutturati vengono memorizzati come _Oggetti data lake non_ strutturati, che vengono mappati alla posizione fisica e ai metadati di ogni documento senza spostare o trasformare il file di origine. **Esempio:** I PDF delle richieste vengono inseriti da _S3_ in _Data 360_ tramite il connettore di archiviazione cloud. Ogni documento è memorizzato come UDLO che punta all'oggetto _S3_. Non si verifica alcuna duplicazione fisica. #### Fase 2: Estrai _Document AI_ elabora ogni UDLO in base a una configurazione schema che definisce i campi da estrarre insieme ai relativi tipi di dati di destinazione. L'UDMO definisce i documenti che rientrano nell'ambito di applicazione. LLM (_GPT-4o_, _Gemini_ o _Claude_) legge ogni documento e restituisce un payload di estrazione strutturato. **Esempio:** _L'intelligenza artificiale_ elabora ogni UDLO in base a uno schema delle richieste che definisce campi come: ClaimID, PatientName, DiagnosisCode, BillingAmount e ServiceDate. Gli LLM leggono quindi ogni PDF e restituiscono un payload di estrazione strutturato. #### Fase 3: Persistere Una volta estratti, i dati persistono nei DLO, che sono lo strato di memoria non formattato di _Data 360_. I DLO conservano i campi estratti senza imporre una logica aziendale, che mantiene una rappresentazione fisica accurata per la trasformazione e la tracciabilità a valle. L'UDLO mantiene un riferimento al documento di origine per abilitare la discendenza a livello di campo in qualsiasi punto della pipeline. **Esempio:** Tutti i campi estratti vengono inseriti in un _DLO Richieste_, che mantiene una rappresentazione grezza e precisa di ogni richiesta con una discendenza completa che può essere ricondotta al PDF di origine. #### Fase 4: Armonizza I campi DLO vengono mappati a DMO allineati al _Customer 360 Data Model_ standard. Questo è il confine in cui i dati derivati dai documenti passano dai campi estratti non elaborati alle entità significative per l'azienda. Il _DLO Fattura viene_ mappato a un _DMO Fattura_ e campi come _CustomerID_ e _BillingAmount_ diventano chiavi join e attributi di corrispondenza all'interno del modello di dati unificato. I dati dei documenti armonizzati partecipano alla segmentazione, agli _approfondimenti calcolati_ e all'attivazione tramite le stesse interfacce utilizzate da CRM e dai dati transazionali. **Esempio:** Il _DLO Richieste_ viene mappato a un _DMO Richieste_. I campi PatientID e PolicyNumber diventano chiavi join che collegano i record richiesta ai profili paziente unificati. #### Fase 5: Unificare I dati DMO armonizzati partecipano alla risoluzione dell'identità. I campi estratti (ad esempio, nomi di clienti, indirizzi email o numeri di account) fungono da chiavi di corrispondenza per collegare i record documento a _Persone unificate (Golden Record)_, colmando così il divario tra documenti e profili. **Esempio:** I campi di estrazione (ad esempio PatientName, DateOfBirth e PolicyNumber) fungono da chiavi di corrispondenza per la risoluzione dell'identità, che collega i record richiesta alla _Persona unificata_ corretta. Ciò si verifica anche se lo stesso paziente appare con ortografie leggermente diverse nei documenti. #### Fase 6: Approfondimenti derivati Gli architetti definiscono gli _approfondimenti calcolati_, ovvero metriche aggregate calcolate in base ai dati dei documenti armonizzati (ad esempio, la spesa totale di varie voci in fattura, i punteggi del rischio di rinnovo dei contratti e gli indici di gravità delle richieste). **Esempio:** _Gli approfondimenti calcolati_ calcolano TotalClaimsPerPatient, AverageClaimAmount e HighRiskClaimScore nei dati delle richieste armonizzati per le query Agentforce. #### Fase 7: Atto I dati armonizzati e risolti in base all'identità sono accessibili agli agenti Agentforce, a _Tableau_, alle piattaforme di marketing e agli _SObject_ Salesforce. Il livello di destinazione è una decisione architettonica determinata dai requisiti di latenza, governance e residenza dei dati. **Esempio:** Un _agente Claims Adjudication Agentforce_ esegue una query sui DMO e gli IC _di Data 360_ per trovare richieste ad alto rischio per la revisione della priorità. I cruscotti digitali _di Tableau_ mostrano il volume delle richieste e le tendenze delle anomalie. I record richiesta approvati tornano all'_oggetto Richieste_ per avviare i flussi di lavoro di pagamento. Nelle architetture _Headless 360_, l'attivazione viene instradata direttamente ai sistemi esterni tramite le destinazioni attivazione del data warehouse _Query API_, _API Pub/Sub_ o Cloud. Quindi, il server MCP trova i dati dei documenti armonizzati e _gli approfondimenti calcolati_ come strumenti richiamabili per gli agenti AI esterni. ### Pipeline di elaborazione transazionale La pipeline di _elaborazione transazionale_ gestisce l'estrazione di un singolo documento in fase di esecuzione senza un UDMO o un UDLO pre-inserito, il che si adatta ai casi d'uso basati sugli eventi (ad esempio, un cliente che carica un modulo, un agente che riceve un PDF o un sistema esterno che avvia l'estrazione all'interno di un flusso di lavoro di elaborazione transazionale). La governance ETL si applica a entrambe le opportunità in corso di realizzazione in modo identico. **Scenario reale** Durante la richiesta di un prestito, un cliente bancario carica un PDF della bolletta tramite l'app mobile della banca. L'evento avvia l'estrazione in tempo reale, il che significa che non sono coinvolti UDLO o UDMO pre-inseriti. ![Opportunità di elaborazione delle transazioni che mostrano l'estrazione dell'API REST sincrona in tempo reale per la bolletta di un richiedente di prestito](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-ad-hoc-processing.png) #### Fase 1: Definizione della configurazione dello schema Prima di invocare l'API, gli architetti devono definire e archiviare in _Data 360_ uno schema che specifica i campi, i tipi di dati e le istruzioni di estrazione in formato _JSON Schema_. A ogni schema viene assegnato un _ID schema_ univoco. In fase di esecuzione, l'applicazione chiamante fa riferimento all'ID schema per mantenere centralizzata la logica di estrazione in _Data 360_ anziché incorporarla nel codice dell'applicazione. **Esempio:** Il team della banca ha uno schema di `ProofOfAddress` predefinito in _Data 360_, che specifica campi come `CustomerName`, `AddressLine1`, `City`, `PostCode` e `DocumentDate`. Queste informazioni sono memorizzate come configurazione con versione a cui può fare riferimento un _ID schema_. #### Fase 2: Invia documenti L'applicazione chiamante invia il documento e l'ID schema in una singola richiesta API REST come payload con codifica base64 o riferimento al file. Non è necessario alcun inserimento UDLO. _Document AI_ applica l'estrazione del documento e restituisce l'output strutturato in base allo schema fornito. **Esempio:** L'app mobile invia la bolletta come payload con codifica base64 insieme all'ID schema `ProofOfAddress` in una singola chiamata API REST. Questo processo non richiede una fase di inserimento UDLO. #### Fase 3: Estrai LLM elabora l'output OCR rispetto allo schema e restituisce un payload JSON strutturato in modo sincrono. I campi non trovati nel documento vengono restituiti come _nulli_. Il chiamante è titolare della risposta JSON completa e procede all'instradamento. **Esempio:** _L'intelligenza artificiale_ applica OCR al PDF e LLM restituisce un payload JSON strutturato con campi indirizzo estratti. I campi che non vengono trovati (ad esempio, se il `PostCode` manca nella fattura) vengono restituiti come _nulli_. #### Fase 4: Percorso a destinazione (facoltativo) Una volta estratto, il payload JSON può essere instradato a uno o più livelli di destinazione a seconda del caso d'uso: - **SObject Salesforce:** Mappa direttamente ai campi _SObject_ tramite _Apex_ o _Flusso_ per i flussi di lavoro e le approvazioni CRM. - **Pipeline DLO/DMO di Data 360:** Instrada a un DLO per armonizzazione, risoluzione dell'identità, _approfondimenti calcolati_ e radicamento Agentforce. - **RDBMS esterno o Data Warehouse:** Instrada tramite _MuleSoft_, chiamata _Apex_, _Eventi piattaforma_ o ETL per i sistemi esterni a Salesforce. - **Integrazione personalizzata:** Restituisce payload JSON strutturati all'applicazione chiamante per l'archiviazione in qualsiasi sistema esterno o archivio dati. - **Flusso a valle o agente:** Passa l'output JSON strutturato direttamente a un flusso o a un agente a valle senza alcuna persistenza in un _SObject_. Questo è uno schema comune per i clienti che utilizzano _l'intelligenza artificiale documenti_ come fase di estrazione in tempo reale all'interno di un flusso di lavoro di automazione o agente più ampio. Tenere presente che un singolo schema può estendersi contemporaneamente a più livelli, con gruppi di campi diversi che instradano a destinazioni diverse dallo stesso punto di estrazione. **Esempio:** Un payload `ProofOfAddress` può essere distribuito contemporaneamente a tre livelli (ad esempio, `CustomerName` e `AddressLine1` scrivono nel _Contact SObject_), il che avvia un _flusso di_ verifica dell'indirizzo. Quindi, il payload completo viene instradato in un DLO per l'armonizzazione e il calcolo del punteggio del rischio, e una copia viene instradata al sistema KYC della banca tramite _MuleSoft_ per la registrazione della conformità normativa. #### Fase 5: Atto Una volta scritti, i dati estratti si attivano immediatamente nel sistema di destinazione. Per le destinazioni _SObject_, i trigger, i flussi e i processi di approvazione vengono attivati nel record inserito con aggiornamento. Per le destinazioni _DLO/DMO_, i dati entrano nella pipeline di _armonizzazione e risoluzione_ dell'identità e nel contesto Agentforce. Per le destinazioni _RDBMS_ esterne, i dati sono disponibili per le query a valle non appena viene completata la scrittura. **Esempio:** Il _flusso di verifica_ dell'indirizzo si attiva immediatamente nel record _Referente_ inserito con aggiornamento, il che fa avanzare la richiesta di prestito alla fase successiva. L'_agente dei prestiti_ Agentforce trova l'indirizzo verificato da _Data 360_ e il sistema KYC registra l'invio del documento per scopi di controllo. ## Quando utilizzare l'intelligenza artificiale dei documenti? _Document AI_ è più adatto a condizioni architettoniche specifiche. L'applicazione al di fuori di tali condizioni introduce una complessità inutile e costi aggiuntivi. In qualità di architetti, è importante valutare questo criterio prima di impegnarsi a utilizzare _Document AI_ come meccanismo di estrazione. **Utilizzare AI documento quando:** - **I documenti sono la fonte di dati principale.** Le informazioni richieste esistono solo sotto forma di documento e non sono disponibili da un'API o un database strutturato (ad esempio, contratti scansionati, rapporti di laboratorio, moduli di accettazione o richieste di risarcimento assicurativo). - **I layout dei documenti variano a seconda delle fonti.** Lo stesso tipo di documento arriva da più fornitori, partner o regioni con posizioni e formati di campo diversi. L'estrazione LLM basata su schema si adatta senza manutenzione per layout. - **I dati estratti devono alimentare Data 360 o Agentforce.** L'estrazione deve partecipare alla risoluzione dell'identità, agli _approfondimenti calcolati_ o al radicamento Agentforce. _L'intelligenza artificiale_ viene fornita direttamente nella pipeline _DLO/DMO_ senza un livello ETL separato. - **Il volume giustifica l'automazione governata.** Il volume dei documenti supera quello che l'elaborazione manuale può gestire senza costi di manodopera misurabili o rischi per la qualità dei dati. - **I documenti contengono contenuti regolamentati.** _I dati personali_, _le informazioni personali_ o i dati finanziari devono passare attraverso un livello di mascheramento delle informazioni personali a conservazione zero prima di raggiungere un livello LLM. L'ETL soddisfa questo requisito in modo nativo. I clienti che non richiedono la permanenza del contenuto estratto in alcun punto devono anche considerare il flusso _API transazionale_, che restituisce l'output strutturato direttamente all'applicazione chiamante senza scrivere in alcun _SObject_ o archivio dati. - **Il caso d'uso è basato sugli eventi.** Un documento arriva in fase di esecuzione (ad esempio, il caricamento di un cliente, un allegato PDF dell'agente o un trigger di sistema esterno). La pipeline di _elaborazione delle transazioni_ gestisce l'estrazione sincrona di un singolo documento senza impostazione batch. **Non utilizzare l'intelligenza artificiale dei documenti quando:** - **I dati di origine sono già strutturati.** Se il sistema a monte espone un'API REST, una tabella di database o un file strutturato (ad esempio, CSV, JSON o XML), utilizzare un connettore _Data 360_ standard. L'esecuzione di dati strutturati attraverso una pipeline di estrazione LLM aumenta i costi di latenza e credito senza ulteriori vantaggi. - **I documenti vengono generati automaticamente con uno schema fisso.** I PDF generati dal sistema da un sistema ERP o una piattaforma di fatturazione nota con un layout stabile sono più adatti per un parser deterministico. L'estrazione LLM è progettata per la variabilità e applicarla ai documenti a schema fisso spreca contesto e crediti. - **I requisiti di precisione superano le soglie di confidenza LLM.** _L'intelligenza artificiale_ non garantisce una precisione di estrazione del 100%. Casi d'uso in cui un valore di campo mancante o errato comporta un rischio finanziario, legale o clinico significativo richiede una fase di convalida HITL. Non utilizzare _Document AI_ come unico livello di estrazione per le decisioni con rischi elevati senza un flusso di lavoro di convalida. - **I documenti superano i vincoli della piattaforma.** L'attuale limite di 10 MB di dimensione del file e i vincoli di lunghezza del contesto LLM rendono _Document AI_ inadatto a documenti di grandi o grandi dimensioni senza pre-elaborazione per suddividerli e riassemblarli all'esterno della piattaforma. - **Nota:** Salesforce sta migliorando attivamente questi guardrail di accettazione per espandere le dimensioni dei file, i conteggi delle pagine e le estensioni dei file supportate. I vincoli continueranno a evolversi in futuro. ## Casi d'uso: Rivedere gli schemi nella pratica ### Casi d'uso delle opportunità in corso di realizzazione batch Vediamo in dettaglio diversi scenari che utilizzano la pipeline _Batch AI documento_ supportata da un oggetto di origine UDMO. In questi casi, i dati estratti vengono instradati attraverso la pipeline _DLO/DMO Data 360_ per l'armonizzazione, la risoluzione dell'identità, _gli approfondimenti calcolati_ e l'attivazione Agentforce. Ogni caso d'uso è più adatto per l'elaborazione pianificata o basata sugli eventi di documenti a volume elevato. **Agenteforce Sales: Intelligence** su contratti e fatture I PDF dei _contratti_ vengono inseriti da Cloud Storage tramite la pipeline _batch_. Lo schema estrae ContractValue, RenewalDate, PaymentTerms e CounterpartyName e li mappa ai DMO _Account_ e _Contract_. Gli _approfondimenti calcolati_ derivano i punteggi del rischio di rinnovo. Agentforce avvisa i responsabili account prima della chiusura delle finestre di rinnovo, eliminando la revisione manuale dei contratti e i mancati rinnovi. **Servizio Agentforce: Deviazione del caso e Knowledge Grounding** I PDF _dei sondaggi_ e gli allegati dei casi vengono inseriti tramite la pipeline _batch_. Lo schema estrae gli indicatori di sentiment, le categorie di problemi e le note di risoluzione e li mappa ai DMO _Caso_ e _Articolo Knowledge_. Agentforce esegue una query nella Knowledge Base armonizzata quando il caso viene aperto e individua le fasi pertinenti per la risoluzione dei problemi, riducendo il sovraccarico di ricerca dell'agente. **Agenteforce Health: Elaborazione** di documenti clinici I rapporti di laboratorio, i PDF di accettazione e i moduli clinici scritti a mano vengono inseriti tramite la pipeline _batch_. Lo schema estrae i campi, inclusi _PatientID_, _DiagnosisCode_, _MedicationName_ e _TestResult_, e li mappa ai DMO di _Health Cloud_, che supportano il coordinamento dell'assistenza allineato all'HIPAA e i flussi di lavoro di ricerca clinica. **Servizi finanziari: Automazione** dei documenti di prestiti e imposte Le richieste di prestito, le dichiarazioni dei redditi e i rendiconti dei redditi vengono inseriti tramite la pipeline batch. Lo schema estrae i campi, inclusi AnnualIncome, TaxYear e EmployerName, e li mappa ai DMO _dell'account finanziario_. Gli _approfondimenti calcolati_ uniscono i dati di reddito derivati da documenti e i dati CRM per facilitare il calcolo automatico del punteggio del rischio di credito. Agentforce individua i dettagli del prestito estratto in linea durante le interazioni con il servizio clienti. Questo schema supporta direttamente il caso d'uso [Agente prequalifica prestito](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions) pubblicato nel centro per sviluppatori Salesforce _Agentic Enterprise Solutions_. **HR: Elaborazione** documenti del personale I documenti di orientamento, i moduli fiscali e i PDF di certificazione vengono inseriti tramite la pipeline _batch_. I campi estratti vengono mappati ai DMO _Record dipendente_ e quindi collegati al profilo _Dipendente unificato_. _Flussi_ specifici avviano operazioni di onboarding e controlli di conformità basati sui dati estratti. Questo schema supporta direttamente il caso d'uso Agentic [Automatizza ripresa elaborazione](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions). _L'intelligenza artificiale_ estrae competenze, precedenti lavorativi e qualifiche dai file PDF di ripresa, che Agentforce utilizza quindi per abbinare i candidati ai criteri dei ruoli aperti e instradarli ai flussi di lavoro di assunzione. **Servizi professionali: Intelligence** delle proposte e della ricerca Le serie di proposte e i rapporti di ricerca vengono inseriti tramite la pipeline _batch_. I framework, i benchmark e i riepiloghi coinvolgimento estratti vengono mappati ai DMO personalizzati e quindi indicizzati per la ricerca vettoriale. Agentforce recupera i consigli pertinenti al contesto al momento della query, basati sul contenuto del documento estratto. Questo schema estende lo schema [Ground Agentforce on Website Content](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions). I documenti vengono indicizzati tramite _Document AI_ e svolgono la stessa funzione di base per le risposte degli agenti del contenuto del sito Web indicizzato tramite i connettori _Data 360_. **Stato conformità HIPAA:** Gli schemi _Health Cloud_ descritti in questo documento applicano controlli ETL (ad esempio, conservazione dei dati zero e mascheramento PHI) per gli input di testo. Questi controlli da soli non costituiscono una certificazione HIPAA. Gli architetti che stanno progettando per ambienti clinici regolamentati devono confermare lo stato di certificazione HIPAA corrente con il team di conformità Salesforce prima di impegnarsi in un'architettura basata su _AI documento_ in tali contesti. ### Casi d'uso delle opportunità in corso di realizzazione di elaborazione transazionale Vediamo più in dettaglio diversi scenari che invocano l'API REST _AI documento_ con uno schema che non è legato a un UDMO. I payload JSON estratti vengono instradati direttamente ai sistemi esterni in modo sincrono in fase di esecuzione. **Filiera: Elaborazione fatture fornitore a ERP** Quando un PDF _della fattura fornitore_ arriva in un bucket di archiviazione monitorato o in un gateway email, un trigger evento chiama l'API REST _AI documento_ con la fattura e un ID schema predefinito. Lo schema estrae VendorID, InvoiceNumber, LineItems, TotalAmount, TaxAmount e DueDate. Il payload JSON viene instradato tramite _MuleSoft_ al modulo _ERP Accounts Payable_ con convalida _completa_ dei campi e logica di inserimento con aggiornamento idempotente, che elimina la manutenzione del modello per la variabilità del formato del fornitore. **Operazioni legali: Revisione del contratto a CLM** Quando un PDF _contratto_ viene caricato nel portale legale, il backend chiama l'API REST _AI documento in_ modo sincrono. Lo schema estrae GoverningLaw, IndemnityCapAmount, TerminationNoticePeriod, AutoRenewalClause e CounterpartySignatory. Il payload JSON viene instradato tramite chiamata _Apex_ al sistema di _gestione del ciclo_ di vita. Tutti i campi che non vengono trovati vengono restituiti come _nulli_ e il CLM applica le regole di obbligo predefinite ai valori mancanti. **Richieste assicurative: Primo avviso di elaborazione** delle perdite Quando un contraente invia un modulo _First Notice of Loss (FNOL)_, il portale di backend chiama l'API REST _AI documento in_ modo sincrono. Lo schema estrae PolicyNumber, IncidentDate, IncidentLocation, DamageDescription, ClaimantName e ContactPhone. Il payload JSON viene instradato al database di _gestione delle richieste_ tramite chiamata _Apex_ o ETL, il che crea un record richiesta precompilato che i rettificatori possono esaminare prima dell'apertura della richiesta formale. ## Considerazioni sulla progettazione e modalità di errore Prima di passare alla produzione, è necessario creare progetti per questi scenari di errore. - **Gestione campi nulli:** LLM restituisce _nullo_ per i campi che non può individuare o estrarre con sicurezza. Convalidare la logica di gestione dei valori nulli durante la progettazione dello schema e implementare la logica dei valori predefiniti o dei rifiuti nel livello di integrazione prima di scrivere in qualsiasi destinazione con vincoli _NOT NULL_ o chiavi di corrispondenza richieste. - **Degradazione della qualità OCR:** La precisione OCR si degrada al di sotto dei 150 DPI, su una scrittura irregolare o su scansioni rumorose. Le letture non corrette si propagano nell'estrazione LLM come input danneggiato senza segnali di errore. Applicare una qualità di scansione minima all'inserimento e implementare controlli della soglia di confidenza sui campi numerici e data. - **Disallineamento versione schema:** L'aggiornamento di una configurazione dello schema dopo la pianificazione di un processo batch provoca l'elaborazione dei documenti in volo rispetto alla versione precedente, il che produce campi mancanti o rinominati che interrompono la mappatura a valle. Schemi di versione in modo esplicito e coordinare gli aggiornamenti con le pianificazioni dei processi batch. - **Limite delle dimensioni dei file:** I documenti che superano i 10 MB vengono rifiutati. Gli errori delle opportunità in corso di realizzazione batch sono silenziosi senza il monitoraggio configurato e i chiamanti transazionali ricevono un errore _4xx_. Pre-convalidare le dimensioni dei file all'inserimento e implementare la pre-elaborazione per suddividere o comprimere i documenti che si avvicinano regolarmente al limite. - **Overflow contesto LLM:** I documenti densi o multipagina possono superare la finestra di contesto LLM entro il limite di 10 MB. LLM rilascia silenziosamente il contenuto che supera il contesto. Implementare una strategia di suddivisione che suddivide i documenti in base all'intervallo di pagine e riassembla i campi estratti prima di trasferirli nella destinazione. - **Mascheramento livello Trust che influisce sull'estrazione:** L'ETL funziona a livello di prompt, non a livello di documento, quindi il mascheramento non si applica al contenuto del documento che passa attraverso _l'intelligenza artificiale_. I campi dello schema che dipendono dai valori _PII_ del documento non sono interessati dalle policy di mascheramento ETL. - **Impotenza di scrittura RDBMS esterno:** La pipeline di _elaborazione delle transazioni_ non ha alcuna impotenza incorporata per le destinazioni _RDBMS_ esterne. I tentativi del _livello di integrazione_ creano righe duplicate a meno che la logica di scrittura non gestisca esplicitamente la deduplicazione. Implementare inserimenti con aggiornamento idempotenti utilizzando un fingerprint documento o un ID esterno in tutti i percorsi di scrittura esterni. - **Esaurimento del credito a metà corsa:** Le esecuzioni batch di grandi dimensioni possono esaurire i crediti _Digital Wallet_ prima che tutti i documenti vengano elaborati, il che produce serie di dati DLO incomplete che le fasi a valle visualizzano come completate. Impostare gli avvisi di consumo sul 75% e 90% dei crediti disponibili e limitare le dimensioni dei batch per rispettare il budget di credito per ogni ciclo. - **Limite campi schema — Vincolo architettonico:** _Document AI_ impone un limite di 50 campi per i campi a livello principale in una configurazione dello schema. Questo è un vincolo di tempo di progettazione, non un errore di runtime, e gli architetti devono tenerne conto durante la progettazione del modello di dati e dello schema. - Per i casi d'uso che richiedono un'estrazione più ampia: - Assegnare priorità senza pietà. Restringere lo schema ai campi che determinano il valore dell'automazione, non alla copertura completa dei documenti. - Sfruttare gli oggetti nidificati (fino a 3 livelli; modalità batch solo con l'oggetto di origine) per ridurre il conteggio dei campi a livello di radice senza sacrificare la profondità di estrazione. - Scomporre documenti complessi in più configurazioni _AI documento_ destinate a sezioni documento distinte, scrivere i risultati in DLO separati che si uniscono a valle in _Data 360_. - **Limite dei tassi API:** _Document AI_ impone un limite di 50 chiamate API di estrazione al minuto per tenant. Il limite teorico e' di 300 chiamate al minuto, che e' regolato dal _Gateway Einstein LLM_. Le integrazioni transazionali a volume elevato devono essere progettate con backoff esponenziale, inserimento in area di attesa delle richieste e calcolo del budget della produttività a livello di tenant. Non presumere che la capacità di burst sia disponibile in ambienti di produzione multi-tenant. - **Profilo di latenza API:** Le API di estrazione _AI dei documenti_ sono completamente sincrone. I tempi di risposta tipici variano da 5 a 15 secondi e variano in base alle dimensioni del file e alla complessità dello schema. - Ciò ha implicazioni dirette per l'architettura di integrazione: - Impostare i timeout del chiamante su un minimo di 30 secondi. - Non invocare l'_intelligenza artificiale documento_ nei flussi con requisiti SLA inferiori al secondo. - Tenere presente la latenza nei calcoli della produttività rispetto al limite di traffico per le opportunità in corso di _elaborazione batch_. - **Documenti crittografati e protetti da password:** _Document AI_ non elabora i file protetti da password (per aprire i file sono necessarie password utente) o i file PDF crittografati con una password titolare/autorizzazioni, inclusi i file che si aprono normalmente ma limitano la copia, la stampa o la modifica a livello di _autorizzazione PDF_. - Questo vincolo si trova al confine dell'inserimento: - Progettare le opportunità di _accettazione dei documenti_ per rilevare e instradare i file crittografati a un percorso di _rifiuto_ o _elaborazione manuale_ prima che raggiungano _l'intelligenza artificiale_. - Non affidarsi alla gestione degli errori in fase di esecuzione come cancello principale. ## Allineamento ben progettato _Data 360 Document AI_ è in linea con diversi pilastri del _Well-Architected Framework_ di Salesforce. - **Trust:** L'ETL impone la conservazione zero dei dati con i provider LLM, maschera gli input _PII_ prima che raggiungano il modello e analizza gli output alla ricerca di contenuti sensibili. Gli architetti devono estendere questa postura ai dati estratti a riposo. Il mascheramento a livello di campo nei DLO non viene applicato dall'ETL e richiede policy e _insiemi di autorizzazioni_ _dello spazio dati_ a valle. - **Affidabilità:** Ogni modalità di errore nella sezione _Considerazioni sulla progettazione_ (estrazione campo nullo, lettura errata OCR, mancata corrispondenza della versione dello schema, violazione delle dimensioni del file, overflow del contesto LLM, interferenza del mascheramento ETL, impotenza di scrittura RDBMS ed esaurimento del credito) rappresenta una classe di errore distinta con un segnale di rilevamento documentato e un percorso di risoluzione. - **Eccellenza operativa (gestione del cambiamento):** Il modello di estrazione basato su schema disaccoppia la logica di estrazione dal layout del documento. Quando un fornitore modifica un formato di fattura o un modulo normativo viene aggiornato, gli architetti devono aggiornare una sola configurazione dello schema anziché modificare il codice di integrazione. - **Eccellenza operativa (manutenibilità):** Centralizzare le configurazioni degli schemi in _Data 360_ anziché incorporare la logica di estrazione nel codice dell'applicazione rende l'intento di estrazione esplicito, con versione e controllabile. Tutti i target a valle utilizzano lo stesso contratto schema indipendentemente dal loro livello target. - **Eccellenza operativa (riutilizzo integrazione):** _L'intelligenza artificiale_ espone l'estrazione in più superfici di integrazione: API REST, _Apex_, _Flusso_, _MuleSoft_, _Azioni_ Agentforce e il server MCP. Una singola configurazione dello schema si estende contemporaneamente a più livelli di destinazione senza ricreare la capacità di estrazione per consumatore. - **Ottimizzazione delle risorse e dei costi:** La guida alla selezione delle opportunità in corso di realizzazione, il limite di 10 MB per le dimensioni del file e i vincoli di lunghezza del contesto LLM pre-assemblaggio rappresentano decisioni di progettazione attente alle prestazioni. La sezione _Quando utilizzare_ formalizza le condizioni per i casi in cui _l'intelligenza artificiale_ non è lo strumento giusto (ad esempio, requisiti di latenza al di sotto del secondo, dati di origine completamente strutturati e documenti generati automaticamente a schema fisso). ## Guida introduttiva per architetti Questo è un punto di partenza strutturato per la configurazione di _Data 360 Document AI_ in un ambiente Sandbox. Completare tutte le fasi nel Sandbox prima di passare alla produzione. ### Prima di iniziare Prima di iniziare la configurazione, è necessario confermare: - **Dimensione file:** Verificare che le dimensioni rappresentative dei documenti siano inferiori a 10 MB. - In **corso di realizzazione:** Verificare se il caso d'uso richiede la pipeline _batch_ (supportata da UDMO, a volume elevato) o la pipeline di _elaborazione transazionale_ (gestita da API, a documento singolo). Questo determina tutte le configurazioni successive. - **Livello target:** Verificare dove si trovano i dati estratti: _SObject_ Salesforce, DLO/DMO _Data 360_, RDBMS esterno o una combinazione. - **Dipendenza Agentforce:** Prima di distribuire qualsiasi elaborazione di documenti basata su Agentforce, verificare che nell'organizzazione sia abilitato un [LLM](https://help.salesforce.com/s/articleView?id=ai.generative_ai_large_language_model_support.htm&type=5) supportato (ad esempio, _GPT-4o_) tramite le impostazioni ETL. Agentforce è un prerequisito della piattaforma per _Document AI_. L'intera superficie della funzione _AI documento_, incluse tutte le API di estrazione, non è disponibile finché Agentforce non è attivo nell'organizzazione di destinazione. Tenerne conto nelle valutazioni della preparazione dell'organizzazione e nella sequenza di provisioning. Attendere alcuni minuti perché la disponibilità API si stabilizzi dopo l'abilitazione. - **Impatto disabilitazione Agentforce:** Se Agentforce viene disabilitato dopo che _l'intelligenza artificiale documento_ è stata configurata e distribuita, tutte le operazioni di estrazione (interfaccia utente e API) verranno bloccate immediatamente. Lo stesso vale per la disabilitazione del modello. La disabilitazione del modello sottostante ha un effetto equivalente sulla disponibilità di _AI documento_. In entrambi i casi, le configurazioni dello schema esistenti vengono mantenute e rimarranno visibili (non si verificherà alcuna configurazione o perdita di dati), ma la funzionalità è completamente inutilizzabile finché Agentforce e il modello non vengono riabilitati. Progettare runbook operativi per trattare la disponibilità Agentforce e l'abilitazione del modello come dipendenze sanitarie _AI documento_. - **Consumo di credito/Prezzi:** Utilizzare i crediti _Data 360_ o i _crediti Flex_ per le stime del TCO derivate da documenti di esempio rappresentativi. #### Fase 1: Configurazione di schemi e opportunità in corso di realizzazione - **Creare la configurazione dello schema.** Definire i campi di estrazione, i tipi di dati e le istruzioni in formato _schema JSON_ nell'impostazione di _Data 360 Document AI_. Per la pipeline _batch_, associarla a un UDMO. Per la pipeline di _elaborazione delle transazioni_, crearla senza un oggetto di origine. Registrare l'ID schema. - **Allineare i nomi dei campi al livello di destinazione.** Abbinare i nomi dei campi alle definizioni delle colonne DLO, ai nomi API _SObject_ o ai nomi delle colonne RDBMS. I nomi non allineati creano un sovraccarico di mappatura nel livello di integrazione. - **Configurare l'oggetto di origine UDMO (solo batch).** Definire l'ambito dei documenti e configurare la connettività della fonte di inserimento (ad esempio, _S3_, _Google Cloud Storage_, _Salesforce Files_ o _MuleSoft)_. Verificare che l'account del servizio di inserimento abbia l'ambito delle credenziali _IAM_ o _OAuth_ richiesto. - **Applicare policy di mascheramento delle informazioni personali.** Configurare le policy di _mascheramento dei dati_ nelle impostazioni ETL prima di elaborare qualsiasi contenuto regolamentato. Definire i tipi di campo (_PHI_, _PII_ e identificatori finanziari) da mascherare prima che gli input raggiungano il livello di dettaglio. **Non** rimandare questo passaggio. - **Assegnare l'ambito Spazio dati e gli insiemi di autorizzazioni.** Limitare l'elaborazione allo _Spazio dati_ appropriato e configurare gli _insiemi di autorizzazioni_ per controllare la creazione dello schema, l'esecuzione dei processi batch, la chiamata dell'API REST e l'attivazione a valle. - **Configurare l'autenticazione API (solo pipeline di elaborazione delle transazioni).** Creare un'_applicazione connessa_ con ambiti _OAuth_ cdp_ingest_api e api. Per i chiamanti interni all'organizzazione, utilizzare una _credenziale denominata_ che si collega a una _credenziale esterna_. Per i chiamanti esterni, configurare le credenziali client _OAuth 2.0_ o un flusso JWT-bearer. Testare e convalidare l'estrazione prima di procedere. #### Fase 2: Integrazione e configurazione di destinazione - **SObject write-back:** Implementare un elemento _Apex_ (@InvocableMethod) o _Flow_ che mappa i campi di risposta JSON ai campi _SObject_. Utilizzare Database.upsert() con un ID esterno per evitare duplicati. Applicare la _protezione a livello_ di campo ai campi _SObject di_ destinazione. - **Condotte DLO/DMO di Data 360:** Mappare i campi DLO estratti ai DMO allineati al _Customer 360 Data Model_. Configurare le regole di risoluzione dell'identità per collegare i record documento a _Persone unificate_. Definire _gli approfondimenti calcolati_ e aggiungere DMO per Agentforce. Per la pipeline di elaborazione delle transazioni, instradare prima il payload JSON a un DLO tramite l'API di _inserimento_. - **RDBMS esterno o data warehouse:** Selezionare lo schema di integrazione: _MuleSoft_ (tessuto di integrazione esistente), chiamata HTTP _Apex_ (leggera, nativa dell'organizzazione), _Eventi piattaforma_ con abbonato _Pub/Sub_ (gestito da eventi) o ETL (batch a volume elevato). Implementare inserimenti con aggiornamento idempotenti utilizzando un fingerprint documento o un ID esterno in tutti i percorsi di scrittura esterni. - **Percorsi di attivazione:** Connettere le azioni Agentforce alle configurazioni dello schema per l'estrazione interattiva. Configurare i trigger _di flusso_ o _Apex_ per i flussi di lavoro di elaborazione automatica e stabilire le destinazioni attivazione per ogni gruppo di campi. - **Gestione degli errori (solo pipeline di elaborazione delle transazioni).** Configurare la superficie di risposta HTTP completa: **200** (_esito positivo_, incluse le risposte _nulle_ parziali), **400** (_richiesta non corretta_ o _ID schema non trovato_), **413** (file superiore a 10 MB), **5xx** (errore di servizio). Implementare il backoff esponenziale per _5xx_ tentativi con un massimo di 3 tentativi. Registrare la risposta JSON non formattata e l'ID schema a ogni chiamata. #### Fase 3: Convalida e preparazione per la produzione - **Testare gli schemi con documenti di esempio.** Inviare esempi rappresentativi tramite l'interfaccia _AI documento_ o l'API REST. Verificare la precisione dell'estrazione, la copertura dei campi e la gestione dei valori nulli nelle variazioni del layout. - **Convalidare la gestione dei campi nulli.** Verificare che tutte le destinazioni a valle possano gestire valori _nulli_ per i _campi non trovati_ in un documento. Tenere presente che i vincoli _NOT NULL_ non vengono gestiti in modo esplicito senza valori nulli. - **Pre-convalidare le dimensioni dei file.** Verificare che i documenti di produzione rimangano inferiori a 10 MB. Implementare la preelaborazione per suddividere o comprimere i documenti che si avvicinano regolarmente al limite. - **Convalidare l'estrazione end-to-end.** Per la pipeline _batch_, avviare un'esecuzione completa e verificare che i campi estratti atterrino correttamente in ogni livello di destinazione. Per la pipeline di _elaborazione delle transazioni_, tracciare la risposta JSON attraverso il livello di _integrazione_ fino alla destinazione. Verificare l'esecuzione del trigger e del flusso per le destinazioni _SObject_, il collegamento di risoluzione dell'identità per le destinazioni _DLO/DMO_ e l'impotenza per le destinazioni _RDBMS_. - **Confermare il comportamento del livello Trust.** L'ETL non applica il mascheramento _delle informazioni personali_ al contenuto del documento, quindi l'LLM restituirà i dati delle _informazioni personali_ nei campi estratti così come sono. Verificare che i campi dello schema, l'instradamento dei dati e l'archiviazione a valle siano progettati per gestire in modo appropriato l'output contenente informazioni personali e assicurarsi che gli eventuali requisiti di conformità o conservazione vengano soddisfatti all'esterno della piattaforma. - **Imposta avvisi Digital Wallet.** Configurare gli avvisi consumo al 75% e al 90% dei crediti disponibili. Stabilire limiti di dimensioni dei batch e stime dei tassi ad hoc all'interno del budget di credito per ogni ciclo. - **Convalidare il monitoraggio batch (solo pipeline batch).** Rivedere le percentuali di esito positivo dell'estrazione, le percentuali di campi nulli e il completamento dei processi nella console di monitoraggio di _Data 360_. Confermare la propagazione del tag dall'UDLO attraverso il DLO al DMO nella discendenza dei dati. - **Convalida la gestione degli errori API (solo pipeline di elaborazione delle transazioni).** Testare tutte le condizioni di errore: **413** (documenti superiori a 10 MB), **400** (ID schema non validi), **200** (estrazioni valide con valori nulli parziali). Verificare che la logica di nuovo tentativo venga attivata sulle risposte **5xx** simulate senza creare scritture duplicate. ## Conclusione Questo documento evidenzia le basi architettoniche di _Data 360 Document AI_: - Due pipeline di elaborazione e quando utilizzarle - Modello di configurazione dello schema - Quadro decisionale livello target - Vincoli della tecnologia di base - Modalità di errore - Allineamento del _framework ben progettato_ La [Guida introduttiva per architetti](/docs/architect/it-it/fundamentals/guide/data360-document-ai#guida-introduttiva-per-architetti) fornisce la sequenza di configurazione per una prova di concetto Sandbox. L'impostazione dell'architettura di base supporta i dati derivati da documenti gestiti a livello di _schema_, elaborati tramite una pipeline LLM imposta da ETL e consegnati allo stesso ciclo di vita dei dati _di Data 360_ che governa tutti gli altri dati aziendali. Gli architetti che applicano questi principi (selezione delle opportunità in corso di realizzazione corrette, progettazione di schemi a livello di tipo di documento e progettazione di modalità di errore prima della produzione) creano capacità di estrazione che si estendono e resistono ai requisiti di governance del settore regolamentati. ### Informazioni sugli autori **Yugandhar Bora** è un architetto di ingegneria del software di Salesforce specializzato in architettura dei dati all'interno della piattaforma _Data and Intelligence Applications_. Dirige iniziative dell'_Enterprise Architecture Review Board (EARB)_ incentrate sulla governance dei dati e sui modelli di dati unificati, contribuendo anche alle soluzioni di provisioning automatico della piattaforma. **Ananth Anto** è Direttore della gestione dei prodotti di Salesforce _Data 360_ e guida le iniziative di _intelligenza artificiale documentale e grafico dati_. Con sede a Bangalore, collabora con i clienti aziendali per risolvere le sfide legate all'elaborazione dei documenti e all'intelligenza dei dati nel mondo reale. Si diverte a esplorare i casi d'uso _aziendali_ per l'_intelligenza artificiale generativa (Gen AI)_. **Nishan Naseer** è un architetto di ingegneria del software di Salesforce che si occupa di _elaborazione dati non_ strutturati, pipeline _RAG_ e _intelligence documentale_. È appassionato di sfruttare la potenza dell'intelligenza artificiale per affrontare le sfide del mondo reale e trovare soluzioni creative a problemi complessi dei clienti.