Deployment
It runs inside your landscape,
not beside it
Most AI over enterprise data is a tenant in somebody else's platform, and the security conversation is about how well that tenant is fenced. This one is deployed in your own environment, which changes what there is to ask about rather than how reassuringly it can be answered.
The shape of it
What stays inside, and what is allowed out
Everything below follows from this picture. The dashed box is the only part that is not yours, and the list beside it is everything that ever reaches it.
Your landscape
Your network, your identities, your controls
SAP S/4HANA
Your system of record. Untouched: no transport, no custom ABAP.
AnrilX, on-premise
One deployment, yours. No shared store, no other customer in it.
Your documents and policy
The standards that govern how figures are reported.
Outside the boundary
Everything else
A model provider
Reached for reasoning. Which one, and on what retention terms, is a deployment decision made with you.
What crosses
- The question, and the shape of your catalogue: entity and field names, not rows
- The compiled plan, on its way back
What never does
- Transactional data. Reads are row-capped and made at question time
- Your documents and policy configuration
- Anything at all, for a saved view; re-opening one runs no model call
What follows from it
Six things this settles, and they are separate questions
Worth listing one by one, because your IT and SAP teams read them as six different risks and would otherwise have to raise each one. A single line saying “on-premise” answers none of them.
Your SAP data does not cross the boundary
Reads happen where your system already is. There is no egress path for transactional data to a vendor environment, because there is no vendor environment holding it.
Cross-customer learning is impossible, not forbidden
Most vendors promise not to train on your data. That is a policy, and policies are audited. Here there is no shared store for it to happen in; the guarantee is structural, which is a different class of assurance.
Your authorisations already govern it
AnrilX has no access model of its own to review. A person reaches exactly what their SAP account permits, so the access design your team already approved is the one in force.
No new data-residency question
The data stays where your landscape is. Whatever answer your organisation already has about where SAP data lives remains the answer; there is no second jurisdiction to assess.
Nobody new gets a copy of your SAP data
A shared-SaaS analytics product adds itself to your sub-processor list and takes your data with it. An in-landscape deployment does not, which is one fewer contract amendment and one fewer annual review.
Clean core
Reads go through published OData services rather than modifications. No custom ABAP between the platform and your database, and nothing that has to be rewritten at your next upgrade.
The comparison that matters
Being separate means several things
The word covers a wide range, and the range is the whole argument. These are the rungs, in order, and where a product sits on them decides what your security team actually has to accept.
Shared tenant, logical separation
One store, one index, separated by identifiers and the code that honours them.
Dedicated tenant in the vendor's cloud
Your own store, in their environment, under their operational control.
Managed service in your cloud account
Their software, your account. Better, and the vendor still runs the plane.
On-premise inside your landscape
Your environment, your authorisations, no egress path for SAP data. This is where AnrilX sits.
Both sides
What running it yourself costs you
It is a trade rather than a free win, and the trades are worth knowing before a pilot rather than during one.
-
There is no hosted option. Not a tier we have not built yet: absorbing the running cost would mean holding your data, which is the one thing the architecture exists to avoid.
-
Upgrades are yours to schedule. Running inside your boundary means we cannot patch it for you overnight, so a fix you want is a change your team has to accept and apply.
-
We can be reached for support, which means an agreed access path for our engineers when you want one. It is scoped, logged and yours to revoke, but it is honest to say it exists rather than to imply nobody can ever connect.
-
A model still has to run somewhere. Where inference happens, and under what retention terms, is a deployment decision made with you rather than something this page can answer for every landscape.
What your IT team will ask
What actually gets installed, and where?
An on-premise deployment inside your landscape: the platform, its policy configuration and its index of your SAP service catalogue. It does not install anything into SAP itself: there is no transport, no custom ABAP and no modification, because reads go through published OData services.
Does it hold a copy of our SAP data?
No. Reads are row-capped and made at question time. What the platform indexes is the shape of your system (the service catalogue), not the transactions inside it. That is also why there is no second source of truth to reconcile at close, and why answer speed is bounded by what your system can serve.
How does this affect our security review?
It narrows it. The questions that usually take longest on an AI product (where does our data go, who else is in the tenant, which sub-processors see it, what is the residency position) mostly resolve to “nowhere new” here. What is left to review is the access path, the approval gate and the audit trail, which is the part worth your team's time anyway.
Can we run it in our own cloud account rather than on-premise?
Yes. Inside your landscape means inside your boundary, whichever form that takes. The property that matters is that the environment is yours and the SAP data does not leave it.
Bring your security team to the demo
The deployment model is the part worth pressure-testing, and we would rather they asked the hard questions on the first call than the fifth.