Every company needs an answer to how AI should work on its SAP landscape. The obvious one — an agent with an open connection into the system — regularly fails at security, Basis and the works council. Conjola is the other answer: the AI works exclusively on a defined extract. No production access, no way back, a scope you can audit.
The agent holds an open connection and decides at runtime which calls it makes — reading, and through development interfaces often writing too. It inherits its service user's rights, and everything it reads becomes part of its context.
The system exports defined data once. The entire analysis runs on that copy — by construction with no way back into the system. What leaves the system is your decision, made upfront and verifiably, not the model's at runtime.
To be fair: attached tooling has its place — for developer productivity in the development system, with human review and a tightly cut scope. The same architecture only becomes critical when it is used for analysis and documentation on production-like systems.
Four properties that make approval possible in the first place.
You release defined extracts — documents, metadata, custom-code source. No language model decides ad hoc which additional business data it requests.
A copy has no write path. Even a misguided agent, or one manipulated through system content, cannot change a system it has no connection to.
The extract is the complete record of what was analyzed. Every answer traces back to a concrete data state — and carries forward with the next extract.
No extra service user, no open interface, no additional tool that has to be run and hardened against your production system.
Four steps — only the first one touches your system.
You import our ABAP reports, run them and upload the result. That is the only point of contact with your system — and it is read-only.
The extract becomes processes, feature usage, cloud fit and an analyzed custom-code map — structured and linked instead of raw.
The assistant answers questions and writes functional specs on exactly that basis. It knows your system through the data, not through a connection.
Each further extract updates the technical layer and shows the delta. The business context you entered once stays anchored to it.
The bottleneck for AI in SAP is rarely the model — it is the approval.
Instead of fighting for production access for months, you start with an architecture that security, Basis and data protection can actually assess — and still get real value on day one.
A structured, current knowledge base about your SAP is the precondition for your own AI agents to work meaningfully. Conjola builds exactly that foundation — your further use cases sit on top of it.
In depth on the blog: Connecting AI to your SAP system? Attached vs. detached →
As soon as development works with AI, the direction reverses: Conjola no longer calls a model, a model calls Conjola. Governance then is not about “whether” but about “who may see what” — and that belongs in the access, not in a policy document.
Not the individual developer. Only once tenant administration opens MCP access can anyone issue a token — with the data-protection notice right there, not in a manual.
Every token carries a cap on the effective permission level. It can only lower, never raise; administrative functions stay closed even if the user otherwise holds them.
Whether source code of your custom developments may leave through this access is decided separately from enabling it. Opening the feature map and keeping the code in is a valid answer.
In a short demo we'll show you how Conjola turns your document data into a basis for decisions.
Book a demo