Connecting AI to your SAP system? Attached vs. detached
AI assistants have arrived in the SAP world. Open VS Code with an agent like Claude Code today, set up an ADT or MCP integration, and you can talk to the system directly: read code, query tables, create objects. The demo feels magical — the agent answers in seconds what used to require someone clicking through the system.
Before putting that into production use, it is worth taking a sober look at the architecture. There are two fundamentally different ways to let AI work with an SAP system:
The agent holds an open connection into the system and decides on its own which calls to make — reading, and often writing too.
The system exports a defined set of data once. The analysis runs entirely on that copy — with no path back into the system.
What “attached” really means
A live integration means: a language model decides at runtime which calls hit your system. Four risks follow from that, and they are worth knowing:
- The agent inherits permissions. It acts with the rights of its service user — and in practice those are rarely cut to a minimum. Whatever the user may do, every mistake of the agent may do as well.
- ADT is a development interface. It can change objects and trigger transports. An agent that “just takes a look” often technically has the write path too — and agent mistakes then land in the system, not in the chat window.
- Prompt injection via system content. Everything the agent reads — code comments, table contents, documentation — becomes part of its context. Crafted content can steer its behavior, with exactly the permissions from point 1.
- Data leaving without a clear boundary. With every live query, the agent decides ad hoc which business data flows into the model context. What left the system, and when, is hard to prove after the fact.
In fairness: attached tooling has a legitimate place. For developer productivity in the development system — with human review and a tightly cut scope — it is a real win. It becomes critical when the same architecture is used for analysis and documentation on production-near systems.
Why “detached” is the more robust analysis architecture
For the question “what does our system actually do?”, the AI does not need a connection — it needs data. And that is where the extract approach plays its strengths:
- The scope is fixed before the analysis. You decide once, verifiably, which data leaves the system — not the agent at runtime.
- No way back. On a copy there is no write path by construction. Even a manipulated or misguided agent cannot change a system it has no connection to.
- Auditable and reproducible. The extract is the complete record of what was analyzed. Every answer can be traced back to that state.
- No new hole in the production environment. No additional tool, service user or open interface has to be operated against the production system.
An agent can only do damage where it has a connection. An extract has none.
The actual decision
So the question is not “AI on SAP: yes or no?” — it is: what job does the AI have, and which architecture fits that job? For code assistance in the development system: attached, with review. For analysis, documentation and decision support: detached — with a defined scope and no return channel.
Conjola is built detached throughout: all analyses — including the AI assistant you chat with about your system — work exclusively on the imported extracts. At no point is there a live connection into your SAP system. The answers come from your real data; the way back does not exist.