Omnissa Elara Beta: AI Governance, Shadow AI Discovery and Enterprise Pilot Tests

What Elara is designed to govern​

Omnissa describes Elara as working across its own and third-party environments, combining signals about people, identities, devices, applications and AI with organizational permissions and policies. Its four announced capabilities are:

• Shadow AI discovery: Identify AI applications, models, agents and other tools outside approved inventories or policies.
• Model-access guardrails: Use the Omnissa AI Gateway to authorize access, apply usage controls and meter token consumption across providers.
• Change management: Assess proposed changes against conflicts, freezes and dependencies, then clear, constrain or escalate them for approval.
• Decision evidence: Record actions, authorization and affected resources in a replayable audit trail.

The useful distinction is between knowing that an AI tool exists and deciding whether its next action should proceed. In our analysis, Elara’s value would depend on connecting those two functions reliably: visibility without enforcement can leave administrators watching a problem unfold, while enforcement without sufficient context can block legitimate work.

The shadow AI statistic needs a denominator​

Omnissa’s argument for broader governance includes its finding that unsanctioned AI tools appeared on 75% of enterprise-managed devices. This was not a statistic first introduced with Elara: the company’s August 26, 2026, conference announcement also attributed that figure to its State of Digital Workspace 2026 report. That earlier announcement described the percentage as an average.

The research’s population matters. Omnissa’s March 24, 2026, research release says the study analyzed anonymized, aggregated telemetry from millions of Omnissa-managed enterprise endpoints, collected between January and December 2025 across more than 17 industries. It separately reported nearly 1,000% growth in AI-assistant application usage during 2025. That growth measure is not the same as the proportion of devices containing unsanctioned tools, and neither should be treated as a census of every enterprise fleet.

For administrators, the practical takeaway is to measure their own environment rather than import a vendor’s percentage into a risk register. Discovery results should distinguish approved applications, unauthorized installations and actual usage before teams decide which controls are necessary.

What an enterprise beta should prove​

The launch leaves important boundaries unspecified, including named integrations, supported operating systems, enforcement architecture, pricing and audit-retention details. Omnissa says the beta is available, while its announcement also directs prospective participants to a waitlist; it does not establish unrestricted access or a general-availability date.

A sensible evaluation should therefore begin with a narrow, testable workflow—not an assumption that Elara governs everything already running in the business.

For example, an administrator could use the following hypothetical acceptance test, subject to confirmed integration support:

1. Choose a controlled action. Select a nonproduction change with a known owner, dependency and approval requirement.
2. Define the expected decision. Specify when the action should proceed, be restricted or require human authorization.
3. Test conflicting context. Introduce a change freeze or missing approval and observe whether execution is prevented, rather than merely logged.
4. Inspect the evidence. Confirm that the record connects the requesting identity, policy decision, approver and affected resource.
5. Test the failure path. Ask what happens when a connector, policy service or approval workflow becomes unavailable.

These are proposed evaluation criteria, not documented Elara setup steps or claims of firsthand testing. Windows administrators should likewise require explicit confirmation of coverage for their endpoint versions and business systems before assuming compatibility.

A promising governance idea, with beta-sized caveats​

Elara’s proposition is worth examining: evaluate an action using the wider business context before granting it permission to run. But the decisive questions are operational. Can an action bypass the governance layer? Does a denial reliably stop execution? Can an auditor reconstruct why permission was granted?

Those questions turn an “authority layer” from a product description into an acceptance standard. For enterprise IT teams considering Elara, the next step should be a bounded pilot with measurable enforcement and evidence requirements—not handing a beta the keys to production and hoping the guardrails arrive before the corner.