# How to Add a Private AI Layer to Hyperion and Essbase On-Prem > Source: https://netray.co/erp-help/private-ai-layer-hyperion-essbase-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Essbase is a multidimensional cube, so the AI layer should call approved, parameterised MDX or report tools rather than letting a model write free queries. Authenticate as the end user so Shared Services provisioning and Essbase filters apply, pull narrative context from planning documents and commentary into a local index, and run the model on your own GPUs. Writes to plans stay in Planning forms, with human approval. ## Kind advanced ## System on-prem-apps ## Erp Oracle Hyperion and Essbase on-prem ## Module Private AI layer / EPM and Essbase ## Query how to add AI to Hyperion Essbase on-prem ## Alternate Queries - Essbase MDX LLM natural language query on-premises - Hyperion Planning AI integration without cloud - Essbase REST API AI assistant ## Applies To Oracle EPM (Hyperion) 11.1.2.4 and 11.2.x on-prem with Planning, Financial Management and Essbase; standalone Essbase 21c has a REST API, older Essbase relies on MaxL, Java API and Smart View ## Steps ### Build order for an EPM private AI layer **Items:** - List the cubes (applications and databases) that matter and which questions finance asks of them: variance by entity, forecast vs actual, driver changes. Start with one cube. - Document the dimensions, hierarchies, aliases and member naming, and publish them as a semantic layer the tool server can use to validate member names. - Build parameterised tools (for example variance for entity, account, period, scenario) that generate MDX from validated members. The model chooses a tool and parameters; it does not write MDX. - Authenticate as the end user via SSO and your EPM security provider, so Shared Services provisioning, Essbase filters and Planning access permissions apply. - Index commentary, planning documents, supporting detail text and board packs in a local vector store with entity and scenario as the access label. - Serve the model locally with vLLM or Ollama and render answers with the returned numbers cited next to the tool call. - Keep plan updates in Planning forms or Data Management loads, with an approver, never from the model. ## Sections ### How EPM data is reached **Body:** Essbase stores numbers in a multidimensional database addressed by members, such as Year, Scenario, Account, Entity and Product. The documented access paths are MDX queries, report scripts, MaxL for administration, Smart View for Excel, and, in Essbase 21c, a REST API that can list applications and databases and run queries and jobs. Older on-prem releases rely on the Java API and Smart View. Hyperion Planning keeps its metadata in a relational repository and its data in Essbase; Financial Management (HFM) has its own application tables and APIs. The key design choice: treat the cube as a calculation engine with a strict vocabulary. A model that invents a member name or an unsafe cross-dimensional query produces nonsense or a heavy query. A tool layer that validates member names against the dimension hierarchy, and caps the number of cells returned, prevents both. **Code:** -- MDX built by the tool, parameters validated against the hierarchy SELECT {[Jan],[Feb],[Mar]} ON COLUMNS, {[Actual],[Budget]} ON ROWS FROM [Sample].[Basic] WHERE ([Sales],[East],[Cola]) ### Reference architecture **Body:** The EPM stack stays where it is. A tool server connects to Essbase (or Planning and HFM through their supported interfaces) over an internal service account only for metadata, and uses per-user sessions for data. Commentary and supporting documents come from Planning supporting detail, cell text and the file shares where board packs live; they go to a local index. Generation runs on local GPUs so unpublished forecasts, covenant calculations and board material never reach a third party. An audit service records user, tool, members requested, cell count and answer. For air-gapped finance networks, the only inbound path is the analyst's browser or Teams-equivalent on the internal network; model weights are imported through an approved transfer. ### Security: provisioning, filters and access **Body:** On-prem EPM security is managed in Shared Services provisioning (native directory or an external LDAP/AD), with Essbase filters restricting members and data access by role, and Planning access permissions on members and forms. A shared service account that can read the whole cube defeats this, so connect as the end user wherever the platform allows it, and test with a user who has a restricted filter to prove cells outside that filter never return. Where per-user sessions are not possible, restrict the service account to specific slices, apply the same filters in the tool server from a mapping you verify with the EPM administrator, and treat that mapping as production security code with change control. ### Rollout, sizing and honest limits **Body:** Phase 1 is read-only variance and trend questions on one cube in 6 to 10 weeks; phase 2 adds explanations that combine numbers with commentary; phase 3 prepares plan inputs as drafts for a planner to enter. Sizing is small: the numbers are tiny compared with document corpora, so one GPU node for a 30B-class model is often enough, and the index is limited to commentary and documents. Limits: free-form natural language to MDX is unreliable on large, sparse cubes with custom calculations and Dynamic Calc members; results depend on calc scripts and consolidation order, so verify numbers against Smart View; and if your finance team mostly needs better dashboards, Smart View, Financial Reporting or Oracle's own cloud EPM may be simpler than a custom layer. ## Pitfalls - Letting the model write MDX freely. It will guess member names and may request millions of cells. - Using one broad Essbase account so every user sees the full cube. - Ignoring Dynamic Calc and shared members, which can make returned values differ from a Smart View result. - Allowing a model to update plans. Plan changes should go through forms or loads with approvals. - Indexing board packs without access labels, exposing confidential forecasts to wider audiences. ## Ai Angle ERPray can sit in front of an on-prem Essbase or Planning application as a tool layer: it validates members, runs the approved query as the asking user, shows the MDX or report behind the answer, and combines the numbers with local commentary. It does not change plan data; it drafts inputs for a planner. ## Faq ### Can an LLM generate MDX for Essbase? **Answer:** It can for simple queries, but reliability drops on large cubes. A safer design uses parameterised tools with validated members and result caps, and reserves free-form MDX for an analyst who reviews it. ### Does Essbase have a REST API on-prem? **Answer:** Essbase 21c provides a REST API. Older 11.1.2.x on-prem relies on MaxL, the Java API and Smart View, so check your version before designing the integration. ### How do we keep Shared Services security intact? **Answer:** Authenticate as the end user, let Essbase filters and Planning permissions apply, and test with a restricted user. If you must use a service account, replicate filters in the tool server and review that mapping like production security code. ### Is this worth it versus Smart View? **Answer:** For analysts who are comfortable in Smart View, probably not for pure number retrieval. The value is in combining numbers with commentary and documents, and in giving non-analysts safe access. ## Search terms add AI to Hyperion, Essbase AI integration, Essbase MDX natural language, Hyperion Planning LLM on-premises, Essbase REST API AI, Oracle EPM private AI, HFM AI assistant on-prem, Shared Services security AI, air-gapped Hyperion AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json