# Private natural-language analytics on SAP BW and BW/4HANA, on your own servers

> Source: https://netray.co/erp-help/private-ai-layer-sap-bw4hana-on-prem-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

The safe way to put an LLM on SAP BW is to let it call existing BW queries and composite providers, not raw tables. Queries carry analysis authorizations and business logic, so the model inherits governance. Build a metadata index of queries and InfoObjects so questions map to the right query, serve an open-weight model locally, and keep the layer read-only.

## Kind

advanced

## System

sap

## Erp

SAP BW and BW/4HANA

## Module

Analytics / Private AI

## Query

how to use an LLM with SAP BW/4HANA on-premise

## Alternate Queries

- SAP BW natural language query AI
- BW/4HANA AI assistant analysis authorizations
- SAP BW chatbot without cloud
- SAP BW Easy Query OData LLM

## Applies To

SAP BW 7.5 on any supported database and SAP BW/4HANA 1.0 and 2.0 on-premise. Some features named here (such as open ODS views and aDSO) exist only on later releases; check yours.

## Steps

### Add a private AI layer on BW

**Items:**

Inventory what is already modelled: queries on CompositeProviders and advanced DataStore Objects (aDSO), InfoObjects with texts, and which queries are already trusted by finance and operations. Start from trusted queries, not from base tables.

Choose the access path for each query: OData exposure of BW queries through SAP Gateway (the Easy Query option on supported releases), the XMLA or MDX interfaces many BI tools use, or HANA-generated external views for CompositeProviders where that option is enabled.

Create a technical user, and decide the identity model: per-user calls so analysis authorizations (RSECADMIN) apply natively, or an application layer that mirrors authorization values per user.

Build a metadata catalogue: query technical names, descriptions, characteristics, key figures, units, currency conversion, time dependency and refresh timestamps. Index it so a question like 'scrap rate by plant last quarter' resolves to a query and its variables.

Define tools with typed parameters (query, filters, key figures, period) that call the query interface and return a bounded result set with units and the data-as-of time.

Serve the model locally with vLLM, add result guardrails (row caps, mandatory filters, no export of detail beyond the user's entitlement) and log every call.

Validate against a question set owned by finance or controlling, then roll out to analysts.

## Sections

### What BW gives you that raw tables do not

**Body:**

A BW system is a curated semantic layer: InfoObjects with texts and hierarchies, aDSOs holding harmonised data, CompositeProviders joining them, and queries defining restricted key figures, calculated key figures, currency and unit conversion, and variables for user input. If an LLM generates SQL against the underlying tables, it throws all of that away, and the answer will disagree with the finance report. If the LLM calls the query, the number matches what controlling already trusts.

Reading options depend on the release. BW queries can be exposed as OData services through SAP Gateway (the Easy Query function on supported releases), consumed with MDX or XMLA by BI tools, or, for CompositeProviders with the external SAP HANA view option switched on, read with SQL on the generated view in the HANA database. Open ODS views and aDSO tables can also be replicated outward through ODP-based extraction for a separate reporting store. Pick one primary route and document it.

For retrieval, the most useful content is not the numbers but the metadata: query descriptions, characteristic texts, hierarchy nodes and documentation. A small index of that makes natural-language mapping reliable.

**Code:**

# OData-style call to an exposed BW query (service name and parameters are illustrative; confirm in your Gateway catalog)
GET /sap/opu/odata/sap/ZQRY_SCRAP_RATE_SRV/ZQRY_SCRAP_RATEResults
    ?$select=Plant,CalendarMonth,ScrapRate
    &$filter=CalendarYear eq '2026' and Plant eq '1000'
Accept: application/json

-- Read the generated external HANA view of a CompositeProvider (name illustrative; view exists only if the option is enabled)
SELECT "0PLANT", "0CALMONTH", SUM("SCRAP_QTY") AS scrap_qty
FROM   "_SYS_BIC"."system-local.bw.bw2hana/ZCP_SCRAP/olap"
WHERE  "0CALYEAR" = '2026'
GROUP  BY "0PLANT", "0CALMONTH";

### Reference architecture

**Body:**

Keep the pattern query-first. The tool server exposes a short list of governed queries as tools. A metadata index (query catalogue plus InfoObject texts plus documentation and report definitions) lets the orchestrator choose the right tool and the right variables. The model, served on local GPUs, writes the narrative and flags caveats: data as of time, units, currency, and whether the query is time dependent.

Because BW often feeds executive reporting, put controls on top. Return result tables alongside the narrative so every number is checkable. Refuse to compute across queries unless the tool contract says the definitions are compatible. Add data-as-of timestamps from the load status (process chain completion) so the assistant can say when data was last refreshed.

For air-gapped installs the whole layer runs in the same enclave as BW. There is no dependency on SAP Analytics Cloud or any internet service, though you give up SAC's own natural-language features.

**Code:**

BW queries (CompositeProvider / aDSO) --OData / MDX / HANA view--> tool server (typed params, row caps)
Metadata: query catalogue + InfoObject texts + docs --> retrieval index
Chat UI -> orchestrator -> vLLM (local GPUs) -> tool server -> table + narrative + data-as-of
Identity: SSO user -> BW user (analysis authorizations applied by BW)
Audit: user, question, query, variables, row count, hash of result

### Permissions: analysis authorizations

**Body:**

BW restricts data with analysis authorizations (maintained in RSECADMIN, and checked in addition to the ordinary role-based authorizations), which grant access by characteristic values and hierarchy nodes, for example cost centre ranges or plants. They are applied by the OLAP engine when a query runs as a user. This is the key advantage of query-based access: if the call runs as the asker, BW applies the restrictions and the assistant cannot show more.

If you must use a technical user (for example for a replicated reporting store), you lose that protection and have to rebuild it. Export the analysis authorization values per user, store them with the replicated data as filterable columns, and apply them as mandatory filters. Treat this like any mirrored model: refresh on role changes, test with restricted users, and fail closed.

BW is an analytics system; writing back is rarely appropriate. Planning functions in BW Integrated Planning exist but should stay with planning users and their own front ends. The AI layer stays read-only.

### Sizing, rollout and limits

**Body:**

As ranges: BW users number fewer than ERP users, often 20 to 200 analysts and managers, and questions are heavier because results are large. A 30B to 70B model on one to three GPUs usually covers it. The metadata index is small (megabytes to low gigabytes); documents attached to reports add more. Plan for result sizes and BW query runtime rather than model throughput as the bottleneck.

Phases: first, a catalogue and natural-language lookup of existing queries and their definitions ('which query shows scrap by work centre?'), which is safe and useful; second, governed query execution with narrative answers; third, scheduled summaries that analysts review before sending.

Limits. LLMs are weak at arithmetic across large result sets, so do the maths in BW or in code and let the model explain. Ad hoc questions that need a new key figure still need a BW developer. If your users already live in SAP Analytics Cloud or Analysis for Office and their needs are covered, adding an AI layer may not pay back. Release differences between BW 7.5 and BW/4HANA affect which exposure options exist.

## Pitfalls

- Generating SQL over base tables and producing numbers that disagree with the finance query.
- Calling queries with a technical user and losing analysis authorizations.
- Returning large result sets to the model instead of capped, aggregated tables, producing wrong or truncated answers.
- Omitting data-as-of timestamps, so users trust numbers from a failed load.
- Mixing currencies or units across queries without conversion rules.
- Skipping a validation set owned by controlling before rollout.

## Ai Angle

DataRay and ERPray approach BW the same way: call governed queries and show which query and variables produced a number, keep the model local, and treat the metadata catalogue as the main thing to index. The assistant explains and cross-checks; BW still calculates.

## Faq

### Can an LLM query SAP BW directly?

**Answer:** It can call BW queries through supported interfaces such as OData exposure, MDX or XMLA, or generated HANA views. That is preferable to text-to-SQL on base tables because queries carry business logic, conversions and analysis authorizations. The model should select and parameterise governed queries rather than invent them.

### How are BW analysis authorizations respected?

**Answer:** Run the query as the asking user through SSO so the OLAP engine applies the authorizations. If you must use a technical user, copy each user's authorization values into the AI layer and apply them as mandatory filters, refresh them on role changes, and test with restricted users.

### Is this different on BW/4HANA versus BW 7.5?

**Answer:** The principle is the same, but object types and exposure options differ. BW/4HANA uses aDSOs and CompositeProviders and removes older object types; some HANA view and OData options depend on release and settings. Check what your system supports before choosing the access route.

### When is SAP Analytics Cloud enough?

**Answer:** If your users are already productive in SAC or Analysis for Office, your data policy permits SAC, and questions are mostly standard dashboards, you may not need more. A private layer is justified when data must stay on premises or when answers must combine BW with documents and other systems.

## Search terms

SAP BW LLM, BW/4HANA natural language query, SAP BW AI assistant, BW analysis authorizations AI, SAP BW Easy Query OData, SAP BW chatbot on-premise, private AI SAP BW, BW/4HANA aDSO CompositeProvider AI

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json