OpenText: l’AI agentica sicura nasce dai dati

Il principale ostacolo alla diffusione dell’AI agentica nelle imprese non riguarda necessariamente la qualità dei modelli. Il problema emerge quando un agente viene collegato a dati frammentati, non classificati, accessibili attraverso autorizzazioni troppo ampie o privi di adeguate misure di protezione.

L’autonomia che distingue gli agenti dai tradizionali assistenti di AI amplifica questa criticità. Un sistema generativo può produrre una risposta inesatta; un agente può utilizzare quella risposta per interrogare altre applicazioni, modificare un processo, trasferire un’informazione o avviare un’azione. La qualità e la sicurezza dei dati diventano quindi condizioni preliminari per affidare all’AI capacità operative.

Il contesto non può essere separato dalla sicurezza

Il patrimonio informativo delle imprese è distribuito tra database, file system, applicazioni SaaS, data lake, repository documentali, sistemi legacy e ambienti on-premise. Rendere queste informazioni disponibili agli agenti richiede un’attività di contestualizzazione, ma anche la capacità di stabilire quali dati possano essere utilizzati, da chi e per quale finalità.

La cosiddetta “context engineering” che definisce quali informazioni, istruzioni e strumenti rendere disponibili a un modello o a un agente, non dovrebbe limitarsi alla selezione di documenti e metadati ma includere anche provenienza, sensibilità, diritti di accesso, policy di conservazione e vincoli normativi.

“Crediamo che si debba portare l’AI ai dati e non i dati all’AI – afferma Pierpaolo Alì, director Southern Europe di OpenText Cybersecurity –  perché solo così si mantiene il controllo su permessi, governance, sicurezza e accessi. Non si tratta soltanto di evitare che un documento riservato venga inserito nel prompt di un modello esterno, ma occorre anche impedire che l’agente possa recuperare, correlare o inferire informazioni che l’utente per conto del quale opera non sarebbe autorizzato a conoscere. Il principio del minimo privilegio deve pertanto estendersi dall’identità umana all’identità dell’agente, alle applicazioni collegate e alle singole operazioni eseguite.”

Proteggere il dato prima che venga utilizzato

La prima misura di sicurezza consiste nel conoscere quali informazioni sono presenti nei sistemi aziendali. La piattaforma OpenText Voltage affronta questa fase attraverso funzionalità di individuazione, classificazione e analisi del rischio.

OpenText Voltage Data Discovery and Risk Insights è progettato per rilevare e classificare informazioni regolamentate e ad alto valore all’interno di repository differenti, applicando regole che consentono di individuare dati personali, finanziari, sanitari o riconducibili alla proprietà intellettuale. Questo permette di decidere quali contenuti possano alimentare un sistema di AI, quali escludere e quali proteggere preventivamente.

La classificazione risolve però solo una parte del problema. Anche un’informazione utilizzabile può contenere elementi che non devono essere esposti in forma originale. Diventa quindi essenziale una protezione data-centric, che applica i controlli direttamente all’informazione anziché affidarsi esclusivamente alla sicurezza del repository, dell’applicazione o dell’infrastruttura.

“Il punto non è costruire una nuova copia dei dati destinata all’AI – sottolinea Alì – ma rendere utilizzabili in sicurezza le informazioni già presenti nell’organizzazione. Questo significa intervenire prima che il dato entri nella pipeline agentica, riducendo la quantità di informazioni in chiaro e mantenendo la protezione anche quando il contenuto viene spostato, elaborato o condiviso”.

Voltage rende persistente la protezione

OpenText Voltage SecureData Servers applica tecniche di cifratura, tokenizzazione, hashing e de-identificazione con l’obiettivo di rendere il dato inutilizzabile a chi non dispone delle necessarie autorizzazioni, preservandone per quanto possibile formato, coerenza e utilità operativa.

Tra le tecnologie utilizzate rientra la Format-Preserving Encryption che consente di cifrare un’informazione mantenendo il formato originario: un numero di carta di pagamento, un codice identificativo o un altro campo strutturato conserva quindi lunghezza e struttura compatibili con le applicazioni che lo elaborano. Per un sistema di AI questo approccio permette, per esempio, di mantenere le relazioni tra record senza esporre necessariamente i valori originali. Un agente può analizzare transazioni, individuare ricorrenze o correlare eventi lavorando su informazioni protette, mentre la restituzione del dato in chiaro rimane subordinata alle regole di accesso.

La protezione è persistente perché accompagna l’informazione durante il suo ciclo di vita, a riposo, durante il trasferimento e nel corso dell’elaborazione. Non dipende quindi soltanto dalla sicurezza dell’ambiente in cui il dato si trova in un determinato momento.

OpenText Voltage SecureData Sentry estende questa impostazione alle applicazioni SaaS, ai prodotti commerciali e ai software sviluppati internamente attraverso l’intercettazione dei dati in transito. In un’architettura agentica questa funzione può creare un punto di controllo tra l’agente, l’applicazione interrogata e il repository contenente le informazioni sensibili.

Dalle connessioni MCP al controllo del comportamento degli agenti

Il collegamento degli agenti a dati e strumenti esterni avviene sempre più spesso attraverso il Model Context Protocol (MCP) che semplifica le integrazioni ma introduce anche nuove categorie di rischio come, per esempio, la manipolazione del contesto, il tool poisoning, l’uso di autorizzazioni eccessivamente ampie.

In questo scenario, la sicurezza non può essere affidata unicamente ai guardrail applicati al modello. Il dato deve essere già protetto prima di raggiungere l’agente; le autorizzazioni devono essere verificate a ogni chiamata; le operazioni devono essere registrate per ricostruire quale identità abbia richiesto un’informazione, quale agente l’abbia elaborata e quale strumento abbia eseguito l’azione.

Anche un agente autorizzato può manifestare un comportamento anomalo a causa di una prompt injection, di un’alterazione del contesto, di una configurazione errata o della compromissione di una credenziale. La governance preventiva deve quindi essere integrata con capacità di osservazione e rilevazione.

OpenText Threat Detection and Response utilizza analisi comportamentale per individuare deviazioni rispetto alle normali attività di utenti e sistemi, compresi l’uso improprio delle credenziali. Lo stesso modello può essere applicato al comportamento degli agenti, verificando frequenza e volume delle interrogazioni, accessi a repository inconsueti, concatenazioni anomale di strumenti e trasferimenti di dati incompatibili con il compito assegnato.