Teradata AI Security aggiunge controlli della privacy mentre gli agenti ottengono accesso

Teradata ha annunciato nuove misure di sicurezza AI il 20 ottobre, rivolte all'esposizione di dati sensibili mentre gli agenti autonomi ottengono accesso ai sistemi aziendali. L'aggiornamento di Teradata AI Security combina protezioni della privacy con funzionalità di sicurezza e ripristino. La sua sfida centrale consiste nel preservare relazioni tra dati utili limitando al contempo ciò che i sistemi automatizzati possono identificare e fare.

Ciò pone gli acquirenti aziendali tra esigenze contrastanti. Gli agenti necessitano di contesto per completare attività utili, ma concedere un accesso più ampio amplia le conseguenze degli errori. Proteggere le informazioni sottostanti è utile, sebbene non risolva chi abbia autorizzato un'azione né se tale azione debba procedere.

Snowflake già presenta l'accesso ai dati governato come parte della propria piattaforma per agenti. Teradata deve quindi affrontare una questione pratica di acquisto: quanta protezione possono distribuire i clienti nei loro ambienti esistenti? Per i team di sicurezza, l'annuncio crea l'opportunità di ridurre l'esposizione esaminando al contempo le autorizzazioni che circondano software sempre più capace.

Teradata AI Security collega la privacy al ripristino operativo

L'annuncio di Teradata include protezione dell'identità, crittografia, backup immutabili e disponibilità del database. I backup immutabili sono copie di ripristino protette da modifiche o cancellazioni. L'azienda presenta queste capacità come requisiti connessi per mantenere operativa l'AI aziendale.

Attraverso Anonomatic, Teradata offre Poly-Anonymization, che sostituisce le informazioni di identificazione personale, o PII, con identificatori stabili separando l'identità sottostante. L'azienda afferma che questo preserva le relazioni necessarie per l'analisi. La sua crittografia con conservazione del formato protegge i valori mantenendo al contempo le strutture previste dalle applicazioni downstream.

Le funzionalità di protezione dei dati includono anche la protezione del trasporto post-quantistica, progettata contro minacce alla crittografia convenzionale poste dai futuri computer quantistici. La disponibilità varia in base alla funzionalità e al deployment. Gli acquirenti dovrebbero distinguere tra le funzionalità cloud attualmente disponibili e quelle pianificate per altri ambienti.

Il valore pratico dell'annuncio dipende da quali protezioni i clienti possono applicare ai loro carichi di lavoro effettivi.

Si consideri un flusso di lavoro illustrativo per l'analisi dei clienti. Un agente potrebbe dover collegare acquisti, interazioni con l'assistenza e cronologie degli account per identificare problemi di servizio ricorrenti. Potrebbe completare tale attività senza ricevere i nomi dei clienti.

Questa distinzione offre ai team della privacy una decisione più specifica rispetto all'approvazione o al rifiuto di un intero dataset. Possono chiedersi quali relazioni richieda l'attività, quali campi identificativi richieda e dove tali requisiti divergano.

La stessa distinzione si applica al ripristino. Una risposta utile richiede informazioni disponibili, ma un database ripristinabile non stabilisce automaticamente un processo aziendale ripristinabile. Un'organizzazione deve anche comprendere quali azioni si siano verificate prima di un'interruzione.

Si immagini un agente che prepara una raccomandazione di servizio quando la sua connessione dati si interrompe. Il ripristino dei record sottostanti supporterebbe il recupero. Determinare se l'agente avesse già inviato quella raccomandazione richiede un registro separato delle sue azioni.

Questi esempi descrivono scenari di valutazione, anziché risultati documentati dei clienti Teradata. Mostrano perché privacy e resilienza appartengano alla discussione di acquisto, preservando al contempo criteri di accettazione distinti per ciascuna capacità.

Un test di privacy chiede se l'agente abbia ricevuto informazioni identificative non necessarie. Un test di ripristino chiede se le operazioni possano riprendere da uno stato affidabile. Superare uno dei due test dice poco dell'altro, a meno che l'organizzazione non esamini il flusso di lavoro completo.

Questo è il significato operativo dell'unione di queste capacità. I clienti ottengono una ragione per rivedere le dipendenze tra team che altrimenti valutano separatamente privacy, comportamento applicativo e ripristino.

Tuttavia, combinare la discussione sugli acquisti non dovrebbe fondere le evidenze. Ogni protezione necessita di un ambito chiaro, di un responsabile identificabile e di un modo per stabilire se abbia funzionato.

I team di sicurezza ereditano decisioni che chi sviluppa agenti non può prendere da solo

La pressione immediata ricade sui team aziendali che approvano l'accesso a informazioni sensibili. Gli sviluppatori di agenti possono definire un'attività, ma non possono decidere autonomamente ogni uso accettabile dei dati sottostanti.

Uno sviluppatore potrebbe ragionevolmente richiedere informazioni sufficienti per migliorare la risposta di un agente. Un responsabile della privacy deve esaminare se l'organizzazione abbia una finalità legittima per esporre tali informazioni. Un team operativo deve considerare gli effetti di un fallimento.

Queste responsabilità si intersecano al momento del deployment. Una dimostrazione può riuscire con input accuratamente selezionati e autorizzazioni ampie. La produzione introduce utenti variabili, richieste non familiari e processi aziendali con conseguenze che vanno oltre la finestra della risposta.

L'accesso degli agenti trasforma un'integrazione tecnica in una decisione sull'autorità delegata.

Per autorità delegata si intende il permesso di agire per conto di qualcun altro. Per un agente aziendale, ciò solleva una domanda diretta: di chi è l'autorità che accompagna ciascuna richiesta?

NIST ha evidenziato questo tema nel suo lavoro del febbraio 2026 sull'identità degli agenti. Il suo documento concettuale ha richiesto contributi su identificazione, autorizzazione, audit e responsabilità per gli agenti software. Tale lavoro fornisce un contesto per valutare le dichiarazioni dei fornitori, anziché certificare un prodotto specifico.

L'implicazione per gli acquirenti è semplice. Riconoscere un agente come applicazione approvata non spiega ogni azione che quell'applicazione dovrebbe eseguire. L'approvazione deve collegare l'attore, l'attività e le informazioni coinvolte.

Un agente illustrativo di assistenza account rende concreta la distinzione. L'accesso ai modelli di transazione potrebbe supportare la risoluzione dei problemi. L'accesso ai record di identità potrebbe diventare appropriato durante una fase di verifica approvata separatamente.

Se entrambe le operazioni utilizzano le stesse credenziali ampie, tale separazione diventa più difficile da applicare. Il sistema può consentire tecnicamente il recupero dell'identità anche quando l'attività corrente non lo richiede.

Al contrario, le restrizioni possono diventare così grossolane da impedire ai dipendenti di completare attività legittime. Questi subiscono quindi pressioni per cercare eccezioni o spostare le informazioni in un flusso di lavoro meno controllato.

Questo crea un compromesso organizzativo. I team di sicurezza necessitano di restrizioni che riflettano le attività reali, mentre i team applicativi necessitano di un comportamento prevedibile quando tali restrizioni si applicano.

Una richiesta negata dovrebbe quindi essere comprensibile. Il dipendente deve sapere se la limitazione rifletta un'autorizzazione mancante, dati non disponibili o un'operazione non supportata. Altrimenti, un confine di sicurezza può sembrare un difetto del prodotto.

L'effetto si estende ai knowledge worker che utilizzano l'AI tra documenti e record aziendali. Una base di conoscenza personale e un repository aziendale condiviso implicano aspettative di accesso diverse. Collegare l'uno o l'altro all'automazione richiede chiarezza su quali informazioni di chi diventino disponibili.

L'annuncio di Teradata avvicina queste decisioni alla discussione sulla piattaforma dati. I clienti necessitano comunque di un accordo tra team di privacy, sicurezza e business prima di espandere ciò che gli agenti possono raggiungere.

Preservare le relazioni tra dati crea un compromesso sulla privacy

Il compromesso centrale riguarda le informazioni di cui un agente necessita per restare utile. Rimuovere l'identità può ridurre l'esposizione, mentre preservare le relazioni consente di continuare l'analisi. Anche tali relazioni possono rimanere sensibili.

Si supponga che un agente illustrativo per il retail studi resi ripetuti tra negozi e cronologie di acquisto. Gli identificatori stabili gli permetterebbero di riconoscere attività ricorrenti senza mostrare il nome di un cliente.

Questo design limita l'esposizione diretta dell'identità. Non rende ogni modello risultante appropriato per ogni dipendente, applicazione o finalità. Una cronologia comportamentale dettagliata può avere un significato sensibile anche senza un identificatore evidente.

Relazioni utili e divulgazione accettabile richiedono valutazioni separate.

Per questo le dichiarazioni sulla privacy meritano una valutazione rispetto al carico di lavoro previsto. Un'azienda dovrebbe esaminare sia i campi che un agente riceve sia le inferenze supportate dalle sue query autorizzate.

La domanda pertinente va oltre la scomparsa dei nomi. Include se l'agente possa assemblare un profilo inutilmente dettagliato, se gli output rivelino modelli sensibili e chi riceva tali output.

Si tratta di implicazioni analitiche dell'architettura proposta, piuttosto che di prove di un difetto nell'implementazione di Teradata. Sono importanti perché una protezione efficace può comunque lasciare decisioni al di fuori del proprio ambito previsto.

Per esempio, separare l'identità dall'analisi stabilisce un confine intorno all'identificazione diretta. Un'organizzazione deve poi decidere quando oltrepassare tale confine serva una finalità aziendale legittima.

Un'indagine sulle frodi potrebbe giustificare il ripristino dell'identità dopo una revisione approvata. Un'analisi di tendenza di routine potrebbe non farlo. Gli stessi record sottostanti possono supportare entrambe le attività, ma l'autorizzazione dovrebbe rifletterne le diverse finalità.

Il flusso di lavoro deve anche gestire il successo parziale. Un agente potrebbe riassumere correttamente un modello ma non riconoscere che un passaggio successivo richieda un'autorizzazione aggiuntiva.

Un sistema che si ferma a quel punto preserva il confine. Un sistema che sostituisce silenziosamente credenziali più ampie cambia il significato dell'approvazione originale.

Questa distinzione aiuta a spiegare perché la protezione della privacy non possa risiedere interamente in un'istruzione che dice al modello come comportarsi. L'applicazione circostante deve rendere indisponibili informazioni e azioni non autorizzate quando manca il permesso.

Spiega anche perché preservare l'utilità analitica meriti evidenze proprie. Un controllo della privacy può proteggere l'identità alterando al contempo la qualità di una particolare attività. Gli acquirenti necessitano di valutazioni rappresentative di entrambi gli esiti.

Tali valutazioni dovrebbero riflettere le domande che i dipendenti pongono effettivamente. Una dimostrazione generica non può stabilire se un dataset protetto supporti una specifica indagine, previsione o procedura di assistenza clienti.

L'obiettivo è un accordo esplicito sulle capacità accettabili. Un agente dovrebbe ricevere un contesto sufficiente per svolgere l'attività approvata, con un processo chiaro per richiedere qualsiasi elemento oltre tale ambito.

Questo accordo offre agli acquirenti un modo per valutare l'approccio di Teradata senza presumere che privacy e utilità siano sempre in conflitto. Alcune attività richiedono meno informazioni identificative di quelle che i flussi di lavoro esistenti espongono abitualmente.

L'opportunità consiste nel riconoscere tali attività e modificarne l'accesso predefinito. La sfida rimanente è preservare questa disciplina man mano che le responsabilità degli agenti si espandono.

I concorrenti rendono l'accesso governato un requisito di base per l'acquisto

Teradata entra in una discussione competitiva già consolidata sulla protezione dei dati aziendali utilizzati dall'AI. Il suo annuncio offre ai clienti esistenti capacità aggiuntive da esaminare nell'ambito delle loro attuali relazioni con la piattaforma.

In un’analisi sulla privacy aziendale di TechTarget, il fondatore di TreeHive Strategy Donald Farmer ha descritto le novità come miglioramenti operativi significativi. Ha inoltre sostenuto che, nel complesso, portano Teradata al livello delle moderne piattaforme dati cloud.

Anche l’analista di BARC Kevin Petrie ne ha accolto positivamente l’allineamento alle priorità aziendali, pur rilevando la presenza di capacità analoghe altrove. Queste valutazioni suggeriscono una lettura equilibrata: utili miglioramenti per i clienti non stabiliscono automaticamente un vantaggio competitivo.

Gli acquirenti dovrebbero confrontare comportamenti applicabili a parità di attività, anziché limitarsi a confrontare i nomi delle funzionalità.

La documentazione di Snowflake descrive Cortex Agents come operativi nel proprio ambiente governato. L’accesso ai dati dipende dai privilegi della piattaforma e dal contesto di esecuzione di ciascuno strumento configurato. La documentazione avverte inoltre che accuratezza delle risposte e citazioni non sono garantite.

Ciò offre un utile punto di confronto senza stabilire un’equivalenza tra le piattaforme. Un vocabolario condiviso sulla governance non implica copertura di deployment, controlli o responsabilità operative identici.

Un’azienda che confronta fornitori dovrebbe partire dalla stessa richiesta aziendale. L’agente dovrebbe affrontare informazioni sorgente equivalenti, autorizzazioni utente equivalenti e azioni consentite equivalenti. Altrimenti, le differenze apparenti potrebbero riflettere la configurazione.

Per esempio, un agente a cui vengono forniti record senza restrizioni può apparire più capace di uno che opera con autorizzazioni limitate. Quel risultato misura tanto l’accesso concesso quanto la capacità dell’agente.

Il confronto dovrebbe includere anche ciò che accade quando cambiano gli accessi. Un dipendente trasferito a un altro reparto non dovrebbe mantenere l’accesso a informazioni sensibili solo perché una conversazione precedente resta aperta.

Analogamente, l’accesso a un’interfaccia per agenti non dovrebbe implicare l’autorizzazione a usare ogni strumento connesso. Un workflow può coinvolgere diversi sistemi con proprietari e regole differenti.

L’ambiente esistente dell’acquirente rende queste distinzioni commercialmente rilevanti. Una capacità integrata con gli attuali processi di identità e operatività può essere più facile da applicare in modo coerente rispetto a una funzionalità isolata.

Tuttavia, la familiarità non dovrebbe sostituire la verifica. Anche i clienti esistenti hanno bisogno di prove che i controlli appena introdotti si comportino come previsto nelle loro condizioni di deployment.

Né una lacuna funzionale dovrebbe determinare automaticamente l’intera decisione sulla piattaforma. I clienti valutano ubicazione dei dati, dipendenze applicative, competenze del personale e requisiti di ripristino insieme alle capacità degli agenti.

La pressione competitiva è quindi specifica. Teradata deve mostrare in che modo le sue protezioni supportino il lavoro governato negli ambienti già in uso presso i suoi clienti.

Per i fornitori concorrenti, vale lo stesso standard. Una dichiarazione sulla governance diventa convincente quando i clienti possono seguire una richiesta dall’identità, attraverso l’accesso ai dati, fino all’azione risultante.

Questo sposta la discussione d’acquisto verso comportamenti osservabili. Il confronto più solido identifica ciò che ciascun sistema consente, ciò che blocca e quali prove restano disponibili in seguito.

La protezione dei dati non stabilisce se un agente debba agire

Privacy, crittografia e ripristino affrontano modalità di guasto differenti. Nessuna di esse determina autonomamente se un agente abbia interpretato correttamente una richiesta o selezionato un’azione appropriata.

Questa distinzione diventa importante quando un agente incontra contenuti ostili. Il prompt injection consiste in istruzioni incorporate in materiale che l’agente dovrebbe trattare come dati.

Il lavoro di NIST sul dirottamento degli agenti descrive come tali contenuti possano reindirizzare un agente verso attività dannose. Sottolinea l’importanza di valutazioni adattive e dell’esame degli esiti di attacchi specifici per attività.

Proteggere un record e controllare l’uso che un agente fa di quel record sono requisiti di sicurezza distinti.

Un ipotetico workflow di assistenza mostra la differenza. Un agente legge un messaggio del cliente mentre prepara un riepilogo interno. Il messaggio contiene istruzioni che gli chiedono di recuperare informazioni non correlate su un account.

La crittografia può proteggere le informazioni durante la trasmissione. La separazione delle identità può limitare ciò che l’agente riceve. Nessuna delle due capacità, da sola, stabilisce che la richiesta incorporata disponga di un’autorità legittima.

L’applicazione necessita quindi di un confine tra le informazioni incontrate durante il lavoro e l’autorizzazione a svolgere ulteriore lavoro. In caso contrario, contenuti non attendibili possono influenzare decisioni oltre il loro ruolo appropriato.

Questo non significa che l’annuncio di ottobre affermi di risolvere ogni problema di sicurezza degli agenti. Significa che i clienti dovrebbero evitare di interpretare un portafoglio di protezione dei dati come una risposta completa al comportamento autonomo.

Teradata ha descritto separatamente Tera Harness come un livello di esecuzione con controlli delle policy e approvazioni umane all’interno del workflow dell’agente. L’annuncio di settembre ha programmato Tera Context Engine, Tera Harness e Agent Skills per il quarto trimestre del 2026.

Queste dichiarazioni dell’azienda stabiliscono la direzione di prodotto prevista. Non dimostrano autonomamente una protezione contro ogni azione non autorizzata o input ostile.

La separazione tra gli annunci è importante. Gli acquirenti dovrebbero verificare quali capacità siano disponibili insieme, quali integrazioni siano supportate e come si comporti il workflow combinato.

Una richiesta può attraversare un confine di privacy, un confine applicativo e un confine di approvazione prima del completamento. Le prove relative a una fase non possono dimostrare che ogni fase successiva resti controllata.

Anche l’approvazione umana necessita di un oggetto concreto. Un dipendente che approva un riepilogo non ha necessariamente approvato un aggiornamento dell’account, un messaggio al cliente o un’esportazione.

Se l’azione proposta cambia dopo l’approvazione, il sistema necessita di una risposta definita. Proseguire automaticamente può scollegare l’azione finale da ciò che il revisore aveva compreso.

Il ripristino introduce un’altra questione. Ripristinare i dati dopo un incidente non annulla un’email già inviata o una decisione già comunicata a un altro sistema.

Un’organizzazione deve quindi identificare le azioni che possono essere ripetute, quelle che richiedono revisione e quelle le cui conseguenze non possono essere ritirate.

Queste osservazioni definiscono i limiti della dichiarazione di sicurezza senza sminuire i miglioramenti sottostanti. Ridurre l’esposizione non necessaria rimane prezioso anche quando sono richiesti controlli aggiuntivi.

La conclusione appropriata è più circoscritta e più utile: la sicurezza AI di Teradata offre agli acquirenti più capacità da valutare, mentre la responsabilità dell’intero workflow degli agenti resta condivisa.

Le prove di deployment definiranno le prossime decisioni d’acquisto

Nei prossimi mesi, le prove più utili riguarderanno copertura del deployment, applicazione durante workflow reali e ripristino in condizioni operative. Questi segnali chiarirebbero come l’annuncio si traduca in una protezione utilizzabile.

Le prove di accettazione da parte dei clienti conteranno più dell’ampiezza della descrizione del lancio.

Il primo segnale è la copertura specifica del deployment. I clienti necessitano di documentazione che identifichi quali protezioni operano nel loro ambiente, comprese dipendenze e condizioni di disponibilità.

La prova che un cliente possa applicare i controlli richiesti all’intero workflow previsto rafforzerebbe l’argomentazione a favore dell’espansione. Lacune di copertura irrisolte restringerebbero gli utilizzi adatti.

Questo non richiede che ogni ambiente supporti immediatamente funzionalità identiche. Richiede che gli acquirenti comprendano il confine prima di approvare l’accesso a informazioni sensibili.

Una limitazione chiara può sostenere una decisione di deployment solida. Una dichiarazione di disponibilità ambigua lascia ai team applicativi il compito di fare supposizioni che i revisori della sicurezza non possono valutare con affidabilità.

Il secondo segnale è l’applicazione osservabile delle policy. Dimostrazioni utili mostrerebbero un agente che completa un’attività approvata, incontra una richiesta soggetta a restrizioni e si ferma al confine corretto.

Le prove dovrebbero identificare l’utente che agisce, l’autorizzazione applicabile e l’operazione tentata. Una risposta finale ben rifinita non può dimostrare che il percorso seguito fosse autorizzato.

Un’applicazione efficace in presenza di autorizzazioni variabili rafforzerebbe la fiducia in un deployment più ampio. Workflow che dipendono da credenziali con privilegi estesi indebolirebbero tale fiducia.

La stessa valutazione dovrebbe considerare il lavoro legittimo. Un sistema che blocca richieste non autorizzate ma impedisce ripetutamente attività approvate genera pressione operativa per le eccezioni.

Questa tensione rende particolarmente utile l’evidenza dei workflow reali. Gli acquirenti devono vedere se le restrizioni restano comprensibili e pratiche quando i dipendenti incontrano informazioni incomplete o richieste insolite.

Il terzo segnale è costituito da prove di ripristino che coprano il workflow dell’agente oltre ai dati sottostanti. Un’esercitazione significativa stabilirebbe quali informazioni siano state ripristinate e quali azioni fossero già avvenute.

Dovrebbe inoltre mostrare come l’organizzazione decida se riprendere, riesaminare o abbandonare il lavoro interrotto. La continuazione automatica è appropriata solo quando le autorizzazioni e le ipotesi pertinenti restano valide.

Un’esercitazione di ripristino che preservi queste distinzioni rafforzerebbe l’argomento della resilienza. Ripristinare i record lasciando incerta la cronologia delle azioni esporrebbe un beneficio operativo più limitato.

Questi sono segnali di valutazione, non traguardi Teradata programmati né previsioni sui futuri risultati dei clienti. Offrono un modo per giudicare le nuove prove man mano che diventano disponibili.

Per gli acquirenti aziendali, l’azione immediata consiste nel selezionare un workflow rappresentativo e definirne le condizioni di accettazione prima di ampliare l’accesso. Specificate le informazioni necessarie, le azioni che può compiere e le approvazioni che restano necessarie. Quindi chiedete ai fornitori di dimostrare tali confini durante l’uso ordinario, le richieste negate e le interruzioni. La sicurezza AI di Teradata merita una valutazione a questo livello di dettaglio. La decisione dovrebbe collegare le protezioni disponibili a un processo aziendale che l’organizzazione possa osservare e governare. Quale workflow di agenti può autorizzare il vostro team con sufficiente chiarezza da spiegare ogni lettura sensibile, azione rilevante e decisione di ripristino?