EDB Semantic Layer inserisce le regole di accesso degli agenti in Postgres

AWS ha pubblicato una guida al semantic layer di EDB che affida alle autorizzazioni del database, anziché alle istruzioni nel prompt, il controllo su ciò che un agente può leggere. Pubblicato il 3 novembre, l’esempio collega EDB Postgres AI ad Amazon Bedrock AgentCore, servizi AWS per ospitare e connettere agenti software. La sua proposta centrale è concreta: mantenere le definizioni aziendali vicine ai dati operativi e applicare i controlli nel punto in cui vengono eseguite le query.

Un semantic layer collega il linguaggio aziendale alle strutture e ai calcoli del database. In questo caso, un agente utilizza Strands Agents, un framework per creare agenti che richiamano strumenti, per rispondere a domande sull’attività dei clienti. La tensione è tra la generazione flessibile di query e un controllo affidabile. Un assistente necessita di sufficiente libertà per interpretare le domande, mentre i proprietari del database necessitano di limiti prevedibili sul suo accesso.

Il confronto con Denodo, una piattaforma di virtualizzazione dei dati che interroga fonti distribuite, aiuta a collocare l’approccio di EDB. Entrambi forniscono agli agenti contesto aziendale, ma organizzano tale contesto attorno a differenti architetture dei dati. Per sviluppatori e acquirenti aziendali, la domanda immediata è dove debbano risiedere definizioni e autorizzazioni, e chi debba mantenerle.

Il semantic layer di EDB rende individuabile il significato del database

Il cambiamento consiste in un modello di integrazione che rende utilizzabili da un agente esterno le definizioni di database esistenti.

La guida all’agentic semantic layer combina l’estensione di database AIDB di EDB con un agente in esecuzione su AWS. Il suo esempio relativo ai clienti utilizza quattro tabelle e una vista derivata, una query salvata presentata come oggetto del database. Le descrizioni aziendali provengono dai commenti del database, mentre le chiavi esterne, vincoli che collegano record correlati, forniscono le relazioni di join.

Secondo AWS, l’esempio mantiene costanti il prompt e il codice dell’agente modificando invece la credenziale del database. Il ruolo con restrizioni non può recuperare una colonna protetta contenente numeri di previdenza sociale. Si tratta di una distinzione utile: il database rifiuta il tentativo di accesso prima che l’assistente componga la propria risposta.

Resta un esempio di riferimento redatto dal fornitore. Stabilisce un’implementazione proposta e riporta comportamenti di esempio, anziché fornire prove indipendenti di affidabilità a livello aziendale. I lettori dovrebbero distinguere tali affermazioni prima di trarre conclusioni sulla prontezza alla distribuzione.

La documentazione di EDB spiega la sottostante base di conoscenza semantica, un indice ricercabile della struttura e delle descrizioni del database. Indicizza tabelle, viste, colonne e commenti invece di incorporare record dei clienti. Gli embedding, rappresentazioni numeriche utilizzate per l’abbinamento basato sulla somiglianza, aiutano gli agenti a individuare oggetti di database pertinenti tramite domande in linguaggio naturale.

Questa distinzione conta nella valutazione. Individuare la struttura corretta non dimostra che un calcolo generato sia corretto. Fornisce al modello materiale migliore per costruire una query. I team devono comunque confrontare le risposte con risultati aziendali accettati.

Per chi cerca una spiegazione del semantic layer di EDB, il punto di partenza utile è questa separazione tra individuazione e applicazione delle regole. Le descrizioni aiutano un agente a decidere quale sia il significato dei dati. Le autorizzazioni determinano se la query proposta possa accedere a tali dati.

Anche la collocazione modifica la titolarità. Un commento del database diventa parte del contesto operativo dell’agente, anziché documentazione che solo gli sviluppatori consultano occasionalmente. Una descrizione inesatta merita la stessa attenzione di un’interfaccia applicativa fuorviante.

Si consideri un ipotetico campo di acquisto il cui nome non riveli se contenga un importo unitario o un totale dell’ordine. Entrambe le interpretazioni consentono calcoli validi. Solo una corrisponde alla definizione aziendale, quindi la sola esecuzione riuscita non può identificare l’errore.

Questo rende l’architettura rilevante oltre il suo dataset di esempio. Il suo valore dipende dalla capacità dei team di trasformare convenzioni di database ambigue in definizioni gestite e individuabili. La connessione dell’agente espone questo lavoro come prerequisito, invece di farlo scomparire.

I proprietari del database ereditano una parte del carico di lavoro degli agenti

Spostare il significato in Postgres conferisce ai team del database un ruolo diretto nella qualità delle risposte.

La pressione immediata ricade sulle persone responsabili di schemi, definizioni di reporting e policy di accesso. Un team applicativo può migliorare le istruzioni di un assistente, ma non può risolvere una definizione aziendale non condivisa con la sola formulazione.

Supponiamo che vendite e finanza utilizzino definizioni diverse di cliente attivo. Una conta gli acquisti recenti; l’altra richiede un account in regola. Un agente che scelga una delle due interpretazioni senza precisazioni produce una risposta che appare più definita di quanto non sia l’organizzazione sottostante.

Mantenere una definizione vicino ai dati crea uno spazio in cui risolvere tale disaccordo. Non stabilisce quale dipartimento abbia ragione. Qualcuno deve comunque avere l’autorità per approvare la definizione, spiegarne l’ambito e gestirne le modifiche.

Per questo il carico operativo merita attenzione insieme all’architettura. Un team che adotta questo modello dovrebbe prevedere un lavoro editoriale continuo sul significato del database. La revisione delle descrizioni diventa parte della manutenzione di un’interfaccia consumata da agenti software.

Lo stesso vale per le relazioni tra tabelle. Una connessione tecnicamente valida non esprime automaticamente la relazione aziendale richiesta da una domanda. Gli acquirenti dovrebbero chiedersi se la struttura esistente del proprio database rifletta esigenze di reporting oppure supporti soltanto le transazioni applicative.

Questa differenza diventa evidente quando un cliente dispone di più indirizzi, titolari di account o classificazioni storiche. Una domanda sul territorio attuale richiede un’interpretazione diversa da una domanda sul territorio nel momento in cui è avvenuto un ordine. Nessuna delle due risposte dovrebbe dipendere da un’assunzione non documentata.

Si tratta di scenari di valutazione, non di malfunzionamenti riportati dell’implementazione di EDB. Mostrano dove una scoperta più solida dello schema necessita ancora di giudizio aziendale. Un pilota utile dovrebbe includere deliberatamente domande le cui risposte cambiano al variare di tali assunzioni.

L’implicazione in termini di personale è diretta. I team che lavorano sugli agenti necessitano dell’accesso alle persone che già risolvono le controversie sul reporting. In caso contrario, gli sviluppatori applicativi rischiano di diventare proprietari non ufficiali di metriche che non hanno l’autorità di definire.

Gli acquirenti aziendali dovrebbero quindi valutare il processo di manutenzione insieme alla dimostrazione dell’agente. Chi approva una definizione modificata? Quali applicazioni dipendono da essa? Come scopre l’organizzazione che un assistente utilizza un’interpretazione obsoleta?

Per i team di ingegneria, una base di conoscenza ricercabile può preservare il ragionamento alla base di tali decisioni. Le definizioni del database e la documentazione di supporto svolgono funzioni correlate, anche quando risiedono in sistemi diversi.

La pressione a breve termine consiste nel preparare un pilota affidabile. La pressione a più lungo termine è organizzativa: mantenere coerenti le definizioni aziendali mentre cambiano applicazioni, requisiti di reporting e personale. L’architettura rende questa responsabilità più visibile, il che è utile solo se qualcuno se ne assume la responsabilità.

Le query revisionate offrono agli agenti flessibili un riferimento stabile

Le domande aziendali ricorrenti meritano una logica di query riutilizzabile, anche quando gli utenti le formulano con parole diverse.

EDB documenta gli alias semantici, query denominate abbinate a descrizioni ricercabili in linguaggio naturale e parametri definiti. Un alias deve contenere un singolo SELECT di sola lettura, una query che recupera risultati. EDB afferma di convalidare tale restrizione quando l’alias viene creato ed eseguito.

L’implicazione architetturale è una via di mezzo tra interfacce di reporting fisse e generazione di query senza restrizioni. Gli utenti possono esprimere conversazionalmente una richiesta familiare, mentre il sistema dispone di una query esistente come riferimento.

Per un ipotetico report sulle vendite regionali, la logica revisionata potrebbe già specificare il periodo di reporting, la classificazione dei clienti e il trattamento degli ordini annullati. Tali decisioni dovrebbero restare invariate al variare della formulazione della richiesta da parte dell’utente.

Questo è diverso dal chiedere al modello di ricostruire ogni decisione ogni volta. Ricostruire una logica familiare introduce un’ulteriore opportunità di variazione. Il riuso offre ai revisori un oggetto più piccolo e concreto da ispezionare.

Tuttavia, una query salvata non risolve da sola l’interpretazione. L’agente deve comunque identificare la query appropriata e fornire parametri adeguati. Una richiesta di attività trimestrale non dovrebbe trasformarsi silenziosamente in una richiesta relativa all’ultimo trimestre solare.

Ciò crea domande di valutazione distinte. Il sistema ha riconosciuto la domanda aziendale prevista? Ha selezionato il periodo e l’ambito corretti? La spiegazione restituita descrive accuratamente ciò che la query ha misurato?

Un risultato favorevole del database affronta solo una parte di questa catena. Un assistente può recuperare i record corretti e riassumerli in modo errato. Al contrario, una spiegazione fluida può celare una query che ha risposto a una domanda vicina ma diversa.

La risposta pratica è mantenere risposte di riferimento per le richieste ricorrenti. I team possono confrontare le risposte generate con tali riferimenti variando formulazione, date e autorizzazioni degli utenti. Ciò verifica il comportamento che gli utenti incontreranno realmente.

La logica revisionata crea anche un processo di modifica più chiaro. Se l’azienda cambia la propria definizione, i responsabili possono individuare la query pertinente e valutare gli output interessati. Senza un riferimento condiviso, definizioni equivalenti possono divergere tra le applicazioni degli agenti.

Esiste un limite a questo vantaggio. Le domande altamente esplorative richiederanno comunque un’interpretazione che vada oltre un catalogo esistente di query. Gli acquirenti dovrebbero valutare il comportamento del sistema quando non esiste una corrispondenza stretta, incluso se richiede chiarimenti.

Il comportamento importante del prodotto è un’incertezza onesta. Uno strumento che identifica una richiesta ambigua offre agli utenti la possibilità di correggerne la direzione. Uno strumento che seleziona con sicurezza una definizione inadeguata nasconde la decisione.

L’approccio di EDB va quindi valutato soprattutto come un modo per organizzare significati e logica di query riutilizzabili. La sua utilità dipende dalla qualità del recupero, dalla gestione dei parametri e dalle pratiche di revisione che lavorano insieme. Nessuno di questi elementi dovrebbe essere dedotto da una dimostrazione riuscita di un altro.

Denodo evidenzia il confine del significato locale al database

Il confronto EDB vs Denodo dipende dalla collocazione dei dati e dalla responsabilità operativa.

La precedente architettura di virtualizzazione dei dati di AWS utilizza Denodo per connettere informazioni sui clienti distribuite tra Amazon Aurora, Amazon Redshift e un database PostgreSQL on-premises. La virtualizzazione dei dati presenta fonti distribuite tramite un livello di query condiviso. Tale guida colloca le viste aziendali e le policy di accesso in Denodo.

L’esempio di EDB, invece, concentra il significato all’interno del proprio database operativo Postgres. Questo confronto non stabilisce un vincitore in termini di prestazioni. Mostra condizioni di partenza differenti per decidere dove debba risiedere una definizione aziendale.

Per un team i cui dati rilevanti risiedono già insieme, le definizioni locali al database meritano considerazione. L'attrattiva organizzativa è immediata: i responsabili del database esistenti dispongono di un luogo familiare in cui esaminare gli oggetti che determinano le risposte.

Per un team le cui informazioni sui clienti si estendono su sistemi indipendenti, il problema centrale è più ampio. Deve riconciliare identificatori, significati e autorizzazioni tra quei sistemi. L'aggiunta di un'interfaccia per agenti non elimina tali decisioni di integrazione.

La domanda utile su EDB rispetto a Denodo riguarda quindi il confine della domanda di business. L'organizzazione può rispondervi attraverso il database governato che già utilizza? Oppure la risposta richiede il coordinamento tra diverse fonti?

Si consideri un ipotetico account manager che chiede quali clienti richiedano attenzione per il rinnovo. La sola cronologia degli acquisti potrebbe non essere sufficiente. Lo stato del contratto, i casi di assistenza irrisolti e la titolarità dell'account potrebbero influire sulla risposta.

Se tali record risiedono altrove, un progetto pilota incentrato sul database dovrebbe rendere visibile questa limitazione. Altrimenti, una risposta corretta sui record disponibili può essere scambiata per una valutazione completa dell'account. La fonte mancante diventa un rischio di business mascherato da successo tecnico.

Un approccio distribuito affronta il proprio onere di valutazione. Collegare le fonti non dimostra automaticamente che le loro definizioni coincidano. Gli acquirenti devono comunque esaminare come il sistema riconcili identificatori e periodi di rendicontazione in conflitto.

La tensione centrale resta la stessa in entrambi gli approcci: gli agenti flessibili necessitano di significati mantenuti e accessi applicabili. La scelta architetturale stabilisce dove si concentrano queste responsabilità, anziché eliminarle.

Ecco anche perché il numero di connettori è un criterio d'acquisto incompleto. Un connettore stabilisce un percorso verso le informazioni. Non stabilisce che una determinata domanda abbia un significato concordato in ogni fonte collegata.

I team dovrebbero confrontare le architetture usando una richiesta di business rappresentativa e tutte le sue dipendenze. Includete i responsabili delle fonti, il calcolo approvato, le restrizioni di accesso e la spiegazione prevista. Questo rivela più di una discussione generale sulle capacità degli agenti.

Per EDB, l'opportunità consiste nel rendere l'attuale struttura del database una base affidabile per gli agenti. Il confine è altrettanto chiaro: un'organizzazione deve stabilire fino a che punto tale base copra le domande che i suoi utenti pongono realmente.

Le autorizzazioni dipendono ancora dall'identità che raggiunge Postgres

Una regola di accesso al database protegge l'utente previsto solo quando la query viene eseguita con un ruolo appropriato.

Il server MCP di EDB utilizza il Model Context Protocol, un'interfaccia standard attraverso cui gli agenti chiamano strumenti esterni. La relativa documentazione afferma che le chiamate agli strumenti vengono eseguite con il ruolo Postgres autenticato. I privilegi del database determinano quindi ciò che quel ruolo può eseguire.

Questo crea un punto di verifica concreto per i team di produzione. Autenticare una persona al confine di un'applicazione e selezionare un'identità del database a valle sono responsabilità separate. I revisori dovrebbero tracciare entrambe prima di accettare un'affermazione sull'accesso specifico dell'utente.

Un ipotetico account di reporting condiviso illustra il problema. Se ogni richiesta raggiunge il database con quell'account, le regole del database valutano le autorizzazioni di quell'account. Un'interfaccia applicativa personalizzata non stabilisce di per sé un'applicazione personalizzata delle regole del database.

Questo non rende gli account condivisi universalmente inappropriati. Significa che la loro autorità deve corrispondere al confine di servizio previsto. Un assistente di reporting con ambito ristretto ha requisiti diversi da un assistente destinato a utenti con diritti di accesso distinti.

Le policy di sicurezza a livello di riga di PostgreSQL limitano i record a cui un ruolo può accedere. Quando è abilitata senza una policy applicabile, la sicurezza a livello di riga prevede il rifiuto per impostazione predefinita. Tuttavia, i superuser e i ruoli con BYPASSRLS aggirano tali restrizioni, mentre i proprietari delle tabelle normalmente le aggirano salvo siano obbligati a rispettarle.

Queste eccezioni documentate sono importanti quando si testa una connessione di un agente. Una dimostrazione che utilizza un account amministrativo non può dimostrare l'isolamento degli utenti ordinari. I valutatori devono verificare il ruolo effettivo e i relativi privilegi per il percorso di richiesta reale.

Anche le restrizioni sulle colonne e quelle sulle righe rispondono a domande diverse. Nascondere un campo sensibile non dimostra che il record di un altro cliente sia inaccessibile. Una valutazione convincente dovrebbe testare le dimensioni dell'accesso promesse dall'applicazione.

Questa valutazione dovrebbe includere tentativi di accesso attraverso domande alternative. Chiedere direttamente un campo sensibile è utile, ma le richieste di business possono combinare attributi consentiti in modi inattesi. I revisori dovrebbero esaminare ciò che l'applicazione restituisce e come spiega le restrizioni.

L'applicazione delle autorizzazioni non dimostra nemmeno la correttezza della risposta. Un ruolo può essere autorizzato a leggere record che l'agente combina in modo errato. La valutazione della sicurezza e quella analitica dovrebbero rimanere distinte, con evidenze per ciascuna.

L'accesso in sola lettura merita una precisione analoga. Impedire le scritture limita ciò che un agente può modificare attraverso quel percorso. Non determina se un risultato autorizzato contenga informazioni che l'applicazione dovrebbe visualizzare in un particolare contesto.

Queste precisazioni definiscono l'ambito dell'affermazione anziché respingerla. L'applicazione delle regole del database offre ai revisori qualcosa di concreto da esaminare. Possono controllare ruoli, privilegi, policy e query eseguite invece di affidarsi esclusivamente alle intenzioni dichiarate dall'assistente.

Il lavoro rimanente consiste nel verificare che l'applicazione raggiunga costantemente quel punto di applicazione delle regole con l'identità prevista. Si tratta di una responsabilità di distribuzione e dovrebbe essere visibile nelle evidenze di accettazione.

Osservate l'isolamento delle identità, le modifiche alle definizioni e le risposte ripetibili

Le prossime evidenze utili mostreranno se la governance resiste ai cambiamenti di utenti, definizioni e volume delle richieste.

Nei prossimi mesi, gli acquirenti dovrebbero cercare valutazioni che colleghino queste dimensioni. Ulteriori dimostrazioni di domande familiari offrono meno informazioni rispetto a test progettati attorno ai confini dell'architettura.

Il primo segnale è l'isolamento delle identità lungo il percorso di richiesta distribuito. Cercate evidenze che utenti con autorizzazioni diverse ricevano risultati appropriatamente diversi. Le evidenze dovrebbero identificare il ruolo effettivo nel database, anziché limitarsi a mostrare nomi diversi in un'interfaccia.

Un test di isolamento dovrebbe includere un tentativo di azione al di fuori dell'autorità dell'utente e il conseguente comportamento del database. Un'applicazione coerente delle regole rafforzerebbe il caso dell'architettura. Una condivisione delle credenziali non spiegata indebolirebbe le affermazioni sulla governance specifica dell'utente.

Il secondo segnale riguarda il modo in cui le modifiche alle definizioni influiscono sulle risposte. Una metrica di business raramente rimane invariata per tutta la vita di un'applicazione. I team dovrebbero cercare dimostrazioni che aggiornino una definizione e verifichino quindi l'interpretazione successiva dell'assistente.

Le evidenze significative includono la transizione stessa. L'assistente utilizza il significato rivisto? I revisori possono identificare quale definizione ha supportato una risposta precedente? Le risposte di riferimento interessate vengono aggiornate tramite un processo esplicito?

Una gestione efficace delle modifiche rafforzerebbe l'argomentazione a favore del mantenimento del significato vicino agli oggetti del database gestiti. Una titolarità poco chiara o interpretazioni obsolete mostrerebbero che la sola co-localizzazione non garantisce coerenza.

Il terzo segnale è la correttezza ripetibile in condizioni d'uso rappresentative. Le valutazioni dovrebbero variare la formulazione delle domande, l'autorità dell'utente e la quantità di attività simultanea. Gli acquirenti devono vedere se il sistema rimane utile quando le condizioni differiscono dalla dimostrazione originale.

Questo non richiede di trattare ogni domanda di business come una competizione tra benchmark. Richiede un insieme dichiarato di comportamenti attesi. Calcoli corretti, rifiuti appropriati, limitazioni comprensibili e tempi di risposta accettabili dovrebbero avere ciascuno delle evidenze.

Per i team che cercano una spiegazione operativa del livello semantico di EDB, questi segnali forniscono un quadro decisionale pratico. Trasformano una proposta architetturale in domande a cui un progetto pilota può rispondere.

Evitano anche una previsione non supportata su quale piattaforma vinca. L'implementazione più efficace dipenderà dalla collocazione dei dati, dai requisiti di identità e dalla capacità dell'organizzazione di mantenere le definizioni. Un approccio incentrato sul database dovrebbe essere valutato rispetto a tali condizioni.

Partite da una domanda di business a cui il vostro team risponde già in modo affidabile, quindi documentatene la definizione, il risultato atteso e i confini di accesso. Fornite ai revisori informazioni sufficienti per riprodurre il risultato senza dover confidare nella spiegazione dell'assistente. Eseguite la stessa richiesta con identità soggette a restrizioni appropriate e analizzate il comportamento del database insieme alla risposta. Successivamente, modificate una definizione rilevante e verificate che la risposta segua la modifica approvata. Utilizzate il livello semantico di EDB per testare una proposizione operativa specifica: la vostra organizzazione può mantenere un significato condiviso applicando al contempo gli accessi al momento della query. Prima di ampliare il progetto pilota, chiedetevi se siete in grado di spiegare ogni risposta importante e ogni rifiuto importante.