Omnissa Elara: controllo delle azioni prima dell’esecuzione

Nel comunicato di Omnissa del 29 settembre 2026, diffuso durante Omnissa ONE a Orlando, la società ha presentato Elara come livello di autorità per gli agenti IA e le azioni aziendali ad alto impatto. Nello stesso annuncio ha indicato una crescita vicina al 1.000% su base annua nell’uso degli assistenti IA sugli endpoint aziendali osservati: più strumenti capaci di agire rendono più difficile capire chi possa autorizzare un cambiamento.

Elara è progettata per valutare identità, contesto e permessi prima che un’azione rilevante venga eseguita. La pagina del prodotto precisa che interviene direttamente dove dispone di un punto di enforcement; altrove consiglia, instrada la decisione o avvia una remediation, e invita ancora a iscriversi alla lista d’attesa della beta. L’annuncio descrive quindi un modello di controllo, mentre la disponibilità generale del prodotto non è indicata.

Dallo shadow AI agli attori da governare

Il percorso inizia dalla scoperta degli strumenti IA presenti sugli endpoint gestiti, compresi quelli installati fuori dall’inventario ordinario. Elara è presentata come capace di individuare applicazioni, modelli, agenti e strumenti basati su MCP. Per l’IT, il primo risultato è sapere quali strumenti siano effettivamente in uso e quali richiedano una decisione: la scoperta rende visibile un’attività, ma non equivale di per sé a impedirla.

Gli strumenti individuati possono essere approvati, limitati o monitorati attraverso i sistemi già utilizzati dall’azienda. Questa distinzione conta per gli agenti che operano usando accessi concessi alle persone: conoscere il nome dell’applicazione non basta a stabilire se una specifica operazione sia consentita. Elara mette in relazione persone, dispositivi, applicazioni, identità e agenti, così che la richiesta venga valutata rispetto ai permessi e alle regole pertinenti.

La verifica prima del cambiamento

Quando un agente o un’automazione propone un’azione ad alto impatto, Elara considera chi la avvia, che cosa potrebbe toccare e chi abbia l’autorità per approvarla. Il contesto comprende anche blocchi temporanei dei cambiamenti, conflitti con altre attività, dipendenze e politiche di approvazione. Un permesso valido nel sistema che esegue l’operazione potrebbe non bastare se un altro sistema segnala una condizione che ne rende rischioso il momento.

Per costruire questo quadro, il prodotto prevede connessioni con Workspace ONE e Horizon, oltre che con strumenti di identità, sicurezza e gestione dei servizi IT. La mappa delle relazioni tra questi sistemi serve a collegare segnali che, presi isolatamente, descrivono solo una parte dell’azione. Nel modello presentato da Omnissa, la decisione riguarda quindi l’operazione concreta e le sue possibili conseguenze sui sistemi collegati, non soltanto il diritto generale di accedere a uno strumento.

L’accesso ai modelli IA segue un percorso di controllo più specifico. Omnissa AI Gateway si colloca tra utenti, applicazioni o agenti e i modelli e strumenti che chiamano: autentica il richiedente, autorizza l’uso, applica regole su dati e richieste e misura il consumo. Controllare una chiamata al modello, però, non esaurisce la valutazione di un cambiamento aziendale: Elara considera anche le condizioni e le approvazioni legate all’azione che l’agente intende compiere.

Intervento diretto, approvazione e traccia della decisione

La differenza decisiva è dove si trova il punto di controllo. Se Elara può intervenire nel percorso di esecuzione, può applicare direttamente la decisione prima che l’azione proceda. Negli altri sistemi può segnalare il rischio, indirizzare la richiesta a chi deve approvarla o attivare una remediation tramite gli strumenti collegati. Dire che ogni operazione viene bloccata automaticamente attribuirebbe al prodotto un potere che dipende invece dall’integrazione disponibile.

La decisione può dunque consentire, limitare o rinviare l’azione a un responsabile. Elara è progettata anche per conservarne il contesto: attori coinvolti, approvazioni, azioni ed esiti possono essere ricostruiti in seguito. È un passaggio distinto dall’enforcement: registrare chi ha autorizzato un cambiamento rende la scelta verificabile, ma non significa che Elara abbia eseguito materialmente il blocco in ogni sistema interessato.

La dimostrazione sugli iPad e lo stato della beta

Nel resoconto di VMblog da Omnissa ONE, Brian Link, responsabile del prodotto, sintetizza l’obiettivo così: «I want to give you control before consequence». Durante la dimostrazione, un aggiornamento del sistema operativo destinato agli iPad di alcuni negozi incontra un blocco dei cambiamenti registrato in ServiceNow: gli stessi dispositivi sono usati per l’inventario in corso. Prima di approvare l’aggiornamento, il responsabile può vedere quanti dispositivi, utenti e servizi sarebbero coinvolti.

La presentazione mostra anche un’applicazione IA non approvata, OpenClaw, per la quale viene impostata una politica che può bloccarne l’uso, limitarlo ad alcuni dispositivi o lasciarlo sotto osservazione. Sono scenari dimostrativi, non risultati misurati presso un cliente. Rendono concreta la separazione tra individuare uno strumento, decidere quale uso sia ammesso e applicare quella decisione attraverso i punti di controllo presenti.

La lista d’attesa per la beta resta il riferimento pubblico per l’accesso a Elara. Quando il prodotto sarà disponibile in più ambienti, sarà la presenza dei connettori e dei punti di enforcement a determinare quali azioni potrà fermare direttamente e quali dovranno passare per un’approvazione o per l’intervento di un altro sistema.