Amazon AWS aggiunge un catalogo agentico, ma i curatori umani mantengono il controllo

Amazon AWS ha introdotto un'esperienza di catalogo agentico che collega Amazon Quick a due importanti cataloghi aziendali, nonostante le persistenti domande sui modelli di dati generati dall'AI.

L'anteprima supporta AWS Glue Data Catalog e Databricks Unity Catalog. I curatori dei dati possono descrivere un caso d'uso analitico in linguaggio naturale, esaminare le risorse consigliate e creare diversi dataset tramite un'unica conversazione guidata.

Questo flusso di lavoro sposta una parte difficile della business intelligence più vicino al catalogo. Invece di ricostruire descrizioni e relazioni all'interno di ogni strumento di analisi, i curatori possono riutilizzare la semantica già mantenuta a monte.

Tuttavia, AWS non ha rimosso il curatore dal processo. La sua documentazione indica agli autori di esaminare tabelle individuate, relazioni inferite e descrizioni ereditate prima di procedere.

Questo avvertimento definisce la vera storia. Amazon Quick sta automatizzando l'assemblaggio di un confine di contesto analitico, ma la qualità di tale confine dipende ancora dal giudizio umano.

Inserisce inoltre Amazon AWS in una competizione più ampia con Databricks e Microsoft. Ogni fornitore vuole che i metadati governati diventino la base dell'analisi conversazionale e degli agenti aziendali.

Amazon AWS trasforma i metadati del catalogo in risorse Quick

L'anteprima trasforma la scoperta dei dati, la creazione di dataset e la configurazione semantica in un unico flusso di lavoro conversazionale.

Un curatore inizia collegando Amazon Quick a un catalogo supportato. L'autore seleziona quindi Explore data e descrive il caso d'uso previsto in linguaggio comune.

AWS propone un esempio relativo alla supply chain nel suo flusso di lavoro agentico. Un curatore richiede dati a supporto di domande sulle prestazioni dei vettori e sui costi di spedizione nei vari centri di distribuzione.

L'agente cerca nei metadati disponibili del catalogo le risorse pertinenti. Tali metadati possono includere descrizioni delle tabelle, descrizioni delle colonne, punteggi di qualità dei dati e informazioni sulla lineage.

Si tratta di qualcosa di più specifico della ricerca di un nome di tabella noto. L'agente dovrebbe associare un obiettivo aziendale a risorse tecniche che possono adottare convenzioni di denominazione diverse.

Il curatore esamina i suggerimenti prima di creare qualsiasi elemento. Dopo l'approvazione, Quick crea insieme i dataset selezionati, anziché richiedere un processo di configurazione separato per ogni tabella.

Questi dataset utilizzano DirectQuery, che invia le query alla fonte collegata invece di importare tutti i dati in Quick. Il catalogo a monte rimane la fonte della verità dichiarata.

Il flusso di lavoro affronta quindi le relazioni. Quick può ereditare le relazioni del catalogo quando esistono e suggerire ulteriori relazioni che deduce dai metadati disponibili.

Infine, l'agente crea un Topic multi-dataset. Un Topic è il livello semantico che aiuta Quick a interpretare il linguaggio aziendale e a generare query tra i dataset selezionati.

Anche le descrizioni vengono trasferite automaticamente a valle. Le descrizioni di tabelle e colonne dal catalogo diventano metadati nei nuovi dataset Quick.

Questa eredità è importante perché il nome di una colonna raramente contiene da solo sufficiente significato aziendale. Un campo denominato revenue potrebbe rappresentare ricavi prenotati, ricavi rilevati o una previsione.

Una descrizione mantenuta può preservare questa distinzione. Senza di essa, un sistema AI deve dedurrelo dai nomi, dai campi vicini e dalla formulazione dell'utente.

L'esperienza di catalogo agentico fa quindi più che individuare tabelle. Riunisce risorse selezionate, relazioni e definizioni in un contesto che Quick può utilizzare per l'analisi.

AWS descrive la capacità come un'anteprima, il che significa che il suo comportamento e le funzionalità supportate restano soggetti a modifiche. Lo stato di anteprima rende inoltre essenziale una valutazione accurata prima di dipendere dalla soluzione in produzione.

Per le connessioni Databricks, AWS afferma esplicitamente che le funzionalità in anteprima non sono generalmente consigliate per carichi di lavoro di produzione critici. Questa precisazione tempera la convenienza promessa dal flusso di lavoro guidato.

Il rilascio resta comunque significativo perché affronta un collo di bottiglia ricorrente. I team di analisi aziendale spesso mantengono metadati preziosi a monte, per poi ripetere gran parte di quel lavoro nelle piattaforme di reporting.

Amazon AWS punta sul fatto che un agente possa trasportare una quota maggiore di quel contesto oltre il confine. Il compito del curatore diventa selezione e verifica, anziché costruzione ripetitiva delle risorse.

Il vero collo di bottiglia è scegliere il contesto giusto

Trovare più dati è facile; definire il più piccolo insieme affidabile per una domanda aziendale resta difficile.

Le grandi organizzazioni possono avere migliaia di tabelle distribuite tra data warehouse, data lake, sistemi operativi e progetti dipartimentali. Un catalogo ampio aiuta a organizzarle, ma l'ampiezza crea un problema proprio.

Un agente di analisi non dovrebbe ricevere ogni tabella disponibile. Risorse aggiuntive introducono campi ambigui, definizioni concorrenti, relazioni irrilevanti e maggiori possibilità di generare query errate.

AWS definisce l'insieme selezionato un confine di contesto mirato. Raccomanda di creare solo i dataset necessari per il caso d'uso previsto.

Questo consiglio rivela perché l'esperienza di catalogo agentico esiste ora. L'analisi conversazionale richiede un contesto più ristretto e meglio descritto di quello normalmente fornito dalla ricerca tradizionale nei cataloghi.

Un analista umano può esaminare più tabelle dai nomi simili e chiedere a un collega quale sia autorevole. Un agente AI ha bisogno che tali distinzioni siano espresse tramite metadati, istruzioni e relazioni governate.

Il nuovo flusso di lavoro cerca di abbreviare il percorso dal catalogo aziendale al contesto utilizzabile. Cerca tra i metadati, propone un sottoinsieme rilevante e trasferisce in Quick la semantica approvata.

Si consideri lo scenario della supply chain. Le prestazioni di consegna potrebbero coinvolgere eventi di spedizione, vettori, centri di distribuzione, contratti, fatture e dimensioni calendario.

Selezionare troppe poche risorse produce risposte incomplete. Selezionarne troppe aumenta l'ambiguità e può esporre campi non pertinenti alle decisioni effettive dei manager.

Il curatore rimane pertanto responsabile dell'ambito. L'AI propone un pacchetto analitico, ma una persona deve decidere se quel pacchetto riflette il linguaggio operativo dell'organizzazione.

Qui l'eredità semantica ha valore pratico. Un catalogo ben mantenuto contiene già definizioni create da data steward ed esperti di dominio.

Riutilizzare queste definizioni riduce il lavoro duplicato e scoraggia la creazione di un altro livello semantico isolato. Offre inoltre all'agente Quick un contesto aziendale più ricco di quello fornito dagli schemi grezzi.

Tuttavia, l'eredità non può migliorare metadati di origine inaccurati. Una descrizione vaga resta vaga dopo che Quick l'ha copiata, mentre una definizione obsoleta può diffondersi con sicurezza in una nuova interfaccia.

I segnali di lineage e qualità aiutano il processo di scoperta, ma non risolvono ogni disputa aziendale. Due tabelle governate possono comunque rappresentare versioni accettate diverse della stessa metrica.

L'agente deve inoltre dedurre l'intento dell'utente da una breve richiesta in linguaggio naturale. Un curatore che richiede dati sul valore del cliente potrebbe intendere ricavi, margine, fidelizzazione o un punteggio composito specifico dell'azienda.

Il linguaggio naturale rende la configurazione più accessibile, ma può nascondere l'ambiguità. Un modulo con scelte esplicite di modellazione talvolta fa emergere prima i disaccordi rispetto a una conversazione fluida.

Il cambiamento importante non è che la modellazione scompaia. La modellazione diventa un'attività di revisione svolta dopo che un agente ha proposto una struttura.

Questa transizione assomiglia ad altri flussi di lavoro di conoscenza assistiti dall'AI. Gli strumenti possono raccogliere e combinare contesto, ma un output affidabile richiede ancora il controllo sulle fonti che entrano nell'insieme di lavoro.

Nella ricerca individuale, lo stesso principio sostiene un'attenta integrazione della conoscenza. L'unità utile non è ogni documento disponibile, ma le prove pertinenti a una domanda definita.

Amazon Quick applica questo principio ai dati aziendali governati. La sua anteprima avrà successo solo se i curatori potranno comprendere perché ogni risorsa e relazione è stata consigliata.

I fornitori di cataloghi ora competono attraverso il livello semantico

Amazon Quick entra in una competizione su quale piattaforma trasformi i metadati governati in risposte AI affidabili.

Databricks considera già Unity Catalog un livello di governance unificato per dati e AI. Applica controlli di accesso, registra la lineage ed espone risorse governate tramite diverse interfacce.

Databricks supporta inoltre la scoperta per parole chiave e semantica per tabelle e colonne registrate. I suoi strumenti di scoperta più recenti consentono agli utenti di esplorare risorse condivise e porre domande in linguaggio naturale.

L'esperienza di scoperta di Databricks si sovrappone a una parte della proposta di Amazon. Entrambi i sistemi usano il contesto del catalogo per aiutare gli utenti a trovare risorse governate pertinenti.

La differenza sta nella destinazione. Amazon Quick utilizza i risultati del catalogo per creare dataset Quick e un Topic multi-dataset per analisi e domande conversazionali.

AWS non sta quindi sostituendo Unity Catalog. Sta trasformando i metadati di Unity Catalog in input per un'esperienza analitica controllata da Amazon.

Questa distinzione rende l'integrazione al tempo stesso cooperativa e competitiva. Databricks fornisce la fonte governata, mentre Amazon Quick diventa il luogo in cui gli utenti aziendali consumano il contesto risultante.

L'anteprima supporta Personal Access Tokens e OAuth a tre vie per le connessioni Databricks. OAuth può anche preservare l'identità del singolo utente quando Quick interroga il sistema a monte.

AWS Glue Data Catalog offre un percorso più integrato verticalmente. Quick può utilizzare un ruolo di servizio o AWS IAM Identity Center per la scoperta agentica e l'eredità semantica.

Per i clienti che utilizzano Lake Formation, la propagazione dell'identità attendibile può applicare le autorizzazioni a monte per ciascun utente. Il sistema di origine determina quali dati quell'utente può interrogare.

La propagazione dell'identità è facoltativa per il flusso di lavoro agentico. Tuttavia, si applica solo ai dataset DirectQuery, secondo la documentazione sulla governance.

Se un dataset passa a SPICE o riceve trasformazioni, l'identità propagata non si applica. I team devono quindi utilizzare i controlli di sicurezza a livello di riga e colonna di Quick.

Questa limitazione è importante perché la governance è centrale nel valore del prodotto. Un processo di scoperta pratico non può compensare un modello di autorizzazioni che i team fraintendono.

Microsoft persegue una strategia correlata attraverso gli agenti dati di Fabric e i modelli semantici di Power BI. Questi agenti collegano domande in linguaggio naturale a fonti di dati governate e definizioni aziendali.

Le linee guida di Microsoft sottolineano che la qualità delle risposte dipende dalla preparazione dei modelli semantici per l'AI. Descrizioni, risposte verificate e istruzioni aiutano l'agente a interpretare correttamente il linguaggio aziendale.

Le sue linee guida sui modelli semantici rafforzano la stessa lezione dell'avvertimento di AWS ai curatori. L'accesso conversazionale funziona meglio quando esiste già un contesto aziendale strutturato.

La competizione non riguarda semplicemente quale modello scriva SQL migliore. Riguarda il controllo del livello tra i dati aziendali grezzi e il dipendente che pone una domanda.

Le piattaforme di catalogo vogliono governare quel livello. Le piattaforme di business intelligence vogliono utilizzarlo e arricchirlo. Le piattaforme agentiche vogliono ragionare su di esso e avviare azioni.

Amazon AWS sta collegando questi ruoli all’interno di Quick. L’anteprima del suo catalogo riduce l’attrito tra i metadati di governance e l’interfaccia analitica finale.

Tuttavia, anche Databricks e Microsoft si stanno avvicinando agli utenti aziendali. Non intendono restare fornitori passivi di metadati mentre un’altra piattaforma domina l’esperienza conversazionale.

Questa pressione favorisce i clienti se incoraggia descrizioni portabili, relazioni esplicite e query consapevoli dell’identità. Crea rischi quando ogni piattaforma aggiunge semantiche proprietarie che non si trasferiscono facilmente.

La scelta architetturale più solida dell’anteprima consiste nel mantenere il catalogo a monte come fonte di verità. Questo approccio limita la creazione di un’altra copia non controllata delle definizioni aziendali.

Il suo valore a lungo termine dipenderà dalla continuità affidabile del flusso delle modifiche. Un processo di ereditarietà una tantum può comunque generare disallineamenti se i successivi aggiornamenti del catalogo non raggiungono le risorse Quick dipendenti.

Come Amazon Quick crea un Topic multi-dataset

Il meccanismo funziona perché Quick converte gli oggetti del catalogo in un modello analitico vincolato, anziché concedere a un agente accesso illimitato a tutto.

I dataset Quick rappresentano le risorse di catalogo selezionate. Dopo che il curatore accetta le sue raccomandazioni, l’agente può creare in blocco diverse di queste risorse.

Il flusso di lavoro collega quindi tali dataset attraverso relazioni ereditate o inferite. Queste relazioni indicano al motore di query come unire i campi provenienti da tabelle separate.

Il Topic risultante fornisce un contenitore semantico per l’analisi in linguaggio naturale. Include dataset, relazioni, definizioni aziendali e istruzioni necessarie per interpretare le domande degli utenti.

Amazon ha recentemente ampliato i Topic multi-dataset attraverso un’anteprima pubblica separata. Un Topic può contenere fino a 12 dataset, secondo la panoramica del livello semantico dell’azienda.

Il motore di query interpreta una domanda, identifica le colonne utili, segue le relazioni definite e costruisce l’SQL necessario. Restituisce quindi una tabella o una visualizzazione.

Questo modello affronta un limite della precedente architettura Quick Sight. Tradizionalmente, un dataset appariva come un’unica tabella appiattita e ogni elemento visivo poteva usare un solo dataset.

Durante la preparazione, i team spesso univano le tabelle sorgenti in un ampio dataset denormalizzato. Questo design semplificava l’esecuzione, ma rendeva più difficili da mantenere i domini complessi.

I Topic multi-dataset consentono ai dataset normalizzati di restare separati. Il livello semantico descrive come sono collegati e Quick crea i join quando una domanda richiede campi provenienti da più risorse.

Per esempio, un Topic per il retail potrebbe collegare vendite, resi, clienti, prodotti, negozi e date. Un responsabile potrebbe chiedere informazioni sui tassi di reso per segmento di clientela e categoria di prodotto.

Nessuna singola tabella contiene necessariamente quella risposta. Il motore deve selezionare le misure corrette, seguire relazioni valide ed evitare di moltiplicare le righe tramite un join errato.

L’ereditarietà dal catalogo può ridurre il carico di configurazione di questo modello. Quando Unity Catalog registra già relazioni e descrizioni, Quick può riutilizzarle invece di richiedere un reinserimento manuale.

AWS Glue fornisce descrizioni di tabelle e colonne, mentre Unity Catalog può fornire anche relazioni. Le capacità esatte dell’anteprima differiscono in base alla sorgente e al metodo di autenticazione.

Le descrizioni sono solo una parte dell’accuratezza semantica. Il più ampio modello di arricchimento di Quick include anche sinonimi, tipi semantici, campi calcolati, esclusioni e istruzioni personalizzate.

Un sinonimo può associare “organico” a un campo con un nome tecnico. Un tipo semantico può indicare al sistema che una colonna contiene valute, date, città o stati.

Le istruzioni personalizzate possono codificare calendari fiscali o definizioni interne. Queste aggiunte restano importanti quando i metadati del catalogo a monte non offrono il livello di dettaglio richiesto per un pubblico specifico.

L’esperienza di catalogo agentica accelera la costruzione iniziale, ma non elimina il perfezionamento a valle. I curatori devono comunque testare domande realistiche e ispezionare i risultati generati.

DirectQuery comporta anche un compromesso operativo. Mantiene dati e autorizzazioni più vicini alla sorgente, ma la velocità delle query dipende dalla piattaforma a monte e dall’SQL generato.

SPICE, il motore di analisi in memoria di Amazon, può migliorare le prestazioni interattive per i dati importati. Tuttavia, l’abbandono di DirectQuery modifica il modello di propagazione dell’identità.

I team devono quindi bilanciare aggiornamento dei dati, prestazioni, governance ed esigenze di trasformazione. L’anteprima non riduce queste scelte a un’unica configurazione universalmente corretta.

Il meccanismo è prezioso perché automatizza attività ripetibili. Può cercare metadati, creare rappresentazioni, ereditare definizioni e assemblare un Topic candidato.

Le decisioni più difficili restano contestuali. I curatori devono scegliere quali risorse appartengono allo stesso insieme, quali relazioni sono sicure e quali definizioni aziendali richiedono ulteriori chiarimenti.

Anche le raccomandazioni fluide richiedono una revisione scettica

Il rischio principale non è un flusso di lavoro palesemente difettoso; è una raccomandazione plausibile che codifica silenziosamente un significato aziendale errato.

AWS invita esplicitamente gli autori a rivedere ogni raccomandazione. Ciò include tabelle individuate, relazioni inferite e descrizioni ereditate dal catalogo sorgente.

L’avvertenza è particolarmente importante per le relazioni inferite. Un nome di colonna condiviso non garantisce che due campi utilizzino la stessa granularità, lo stesso dominio o la stessa frequenza di aggiornamento.

Un identificatore cliente potrebbe rappresentare un account in una tabella e un’entità di fatturazione in un’altra. Unirli può produrre totali credibili ma comunque errati.

La cardinalità crea un altro rischio. Un agente può identificare un join tecnicamente valido, ma non prevedere la duplicazione causata da relazioni molti-a-molti.

Questi errori sono difficili da rilevare perché la dashboard risultante può apparire curata. Anche le spiegazioni in linguaggio naturale possono far sembrare più autorevole di quanto sia una risposta incerta.

I curatori hanno bisogno di domande di test con risultati noti. Dovrebbero confrontare gli output di Quick con dashboard affidabili, query approvate e aspettative dei responsabili di dominio.

La revisione dovrebbe coprire anche i casi negativi. Un Topic affidabile deve sapere quando il contesto selezionato non può rispondere a una domanda in modo sicuro.

La qualità dei metadati resta un altro punto di pressione. I cataloghi contengono spesso descrizioni incomplete, record di proprietà obsoleti e nomenclature incoerenti tra le unità aziendali.

L’ereditarietà semantica conserva il lavoro esistente, ma conserva anche i difetti esistenti. L’automazione aumenta la velocità con cui viaggiano sia il contesto valido sia quello errato.

I punteggi di qualità dei dati possono aiutare a classificare le risorse, ma raramente un punteggio coglie ogni problema semantico. Aggiornamento, completezza e validità non dimostrano che una tabella risponda alla domanda prevista.

La lineage può mostrare da dove provengono i dati e come si sono spostati. Non spiega necessariamente perché finanza e vendite utilizzino definizioni diverse per la stessa etichetta.

La maturità dell’anteprima aggiunge incertezza. AWS non ha pubblicato benchmark indipendenti di accuratezza per il flusso di lavoro completo dal catalogo al Topic nei materiali esaminati.

Non esistono inoltre evidenze pubbliche che mostrino quanto tempo dei curatori la funzionalità faccia risparmiare su cataloghi di dimensioni diverse. Le affermazioni su una consegna più rapida dovrebbero quindi restare affermazioni dell’azienda.

Anche il comportamento multipiattaforma merita analoga cautela. I metadati di Unity Catalog possono essere ricchi, ma le organizzazioni li configurano e mantengono in modo diverso.

Un ambiente Databricks ben governato offre input più utili di un catalogo che contiene soprattutto schemi tecnici. L’integrazione non può creare dal nulla conoscenza istituzionale mancante.

Le autorizzazioni richiedono test deliberati. I team dovrebbero verificare i risultati con diverse identità utente anziché presumere che la connettività al catalogo garantisca un’applicazione corretta.

DirectQuery è necessario per la propagazione dell’identità, ma la propagazione dell’identità stessa è opzionale. Gli amministratori devono comprendere quale piano di controllo protegge ciascun dataset.

Il contesto suggerito dall’agente dovrebbe inoltre restare ispezionabile dopo la creazione. I curatori hanno bisogno di una chiara registrazione delle risorse selezionate, delle definizioni ereditate, delle relazioni inferite e delle modifiche manuali.

Senza questa visibilità, la risoluzione dei problemi diventa più difficile. Una risposta errata potrebbe derivare dai dati sorgente, dai metadati del catalogo, dall’inferenza delle relazioni, dalla configurazione del Topic o dall’SQL generato.

Questo non rende l’anteprima inutilizzabile. Definisce lo standard di valutazione che gli acquirenti aziendali dovrebbero applicare.

Un progetto pilota utile dovrebbe concentrarsi su un unico dominio aziendale circoscritto con risposte di riferimento consolidate. Il team può quindi misurare lo sforzo di configurazione, i tassi di correzione e la coerenza delle risposte.

L’esito migliore non sarebbe l’assenza di coinvolgimento umano. Sarebbe un assemblaggio più rapido, preservando al contempo una proprietà chiara e un percorso di revisione verificabile.

Cosa osservare con l’espansione dell’anteprima

Tre segnali mostreranno se Amazon Quick sta diventando un consumatore semantico affidabile o soltanto un altro luogo in cui riparare i metadati.

Il primo segnale è la qualità del feedback di produzione da parte dei clienti AWS Glue e Databricks. I team dovrebbero osservare con quale frequenza i curatori accettano le raccomandazioni senza correzioni sostanziali.

Tassi di accettazione elevati nei cataloghi ben governati sosterrebbero il meccanismo di AWS. Frequenti sostituzioni di tabelle o riparazioni delle relazioni indebolirebbero l’affermazione sull’automazione.

La sola accettazione non è sufficiente. I clienti hanno anche bisogno di risposte stabili quando più utenti formulano la stessa domanda aziendale in modi diversi.

Il secondo segnale è il modo in cui AWS gestisce le modifiche al catalogo dopo la creazione iniziale. L’ereditarietà semantica ha valore duraturo solo quando i team possono gestire gli aggiornamenti senza disallineamenti silenziosi.

AWS dovrebbe chiarire se modifiche a descrizioni, relazioni, segnali di qualità e lineage confluiscono nelle risorse Quick esistenti. Dovrebbe inoltre spiegare come vengono evidenziati i conflitti.

Una sincronizzazione affidabile rafforzerebbe il modello della sorgente a monte come fonte di verità. Le reimportazioni manuali reintrodurrebbero gran parte del carico di manutenzione che il flusso di lavoro promette di ridurre.

Il terzo segnale è la risposta competitiva di Databricks e Microsoft. Entrambe combinano già dati governati, contesto semantico e interazione in linguaggio naturale.

Databricks può approfondire il proprio percorso dalla scoperta in Unity Catalog all’analisi aziendale. Microsoft può rafforzare i collegamenti tra Fabric, i modelli Power BI e gli agenti dati.

Se queste piattaforme migliorano la portabilità tra sistemi, i clienti ottengono maggiore libertà sul livello di consumo. Se la semantica resta proprietaria, i costi di cambiamento aumenteranno.

La disponibilità generale fornirà un altro punto di controllo pratico all’interno di questi segnali. Gli acquirenti dovrebbero cercare un supporto più ampio per i cataloghi, limiti documentati, controlli amministrativi e affidabilità misurabile.

Amazon AWS ha identificato il giusto problema aziendale. L’analisi AI non può dipendere dai nomi degli schemi e da un accesso illimitato al catalogo.

L’anteprima utilizza anche un confine sensato. L’agente propone risorse e relazioni, mentre il curatore approva ciò che entra a far parte del contesto analitico.

Ora AWS deve dimostrare che questa divisione del lavoro regge alla reale complessità dei cataloghi. Una conversazione fluida per la configurazione è utile, ma un’analisi affidabile richiede una verifica ripetibile.

I team che valutano Amazon Quick dovrebbero scegliere un dominio con metadati maturi e risposte note. Dovrebbero registrare ogni correzione effettuata durante la creazione dei dataset e del Topic.

Dovrebbero poi testare autorizzazioni, comportamento delle relazioni, coerenza delle query e aggiornamenti del catalogo. Queste evidenze riveleranno se il flusso di lavoro riduce il lavoro di modellazione o si limita a spostarlo.

La questione più ampia è rilevante oltre la business intelligence. Ogni agente aziendale necessita di un ponte controllato tra il linguaggio dell’utente e le informazioni effettive dell’organizzazione.

Amazon AWS offre ora una versione di quel ponte. I prossimi mesi dovrebbero mostrare se i curatori riusciranno ad attraversarlo più rapidamente senza rinunciare al discernimento che rende credibili i dati aziendali.