KI ans SAP-System anschließen? Attached vs. Detached
KI-Assistenten sind im SAP-Umfeld angekommen. Wer heute VS Code mit einem Agenten wie Claude Code öffnet und eine ADT- oder MCP-Integration einrichtet, kann direkt mit dem System sprechen: Code lesen, Tabellen abfragen, Objekte anlegen. Die Demo wirkt magisch — der Agent beantwortet in Sekunden, wofür früher jemand durchs System navigieren musste.
Bevor man das produktiv einsetzt, lohnt ein nüchterner Blick auf die Architektur. Denn es gibt zwei grundsätzlich verschiedene Arten, KI mit einem SAP-System arbeiten zu lassen:
Der Agent hält eine offene Verbindung ins System und entscheidet selbst, welche Aufrufe er macht — lesend und oft auch schreibend.
Das System exportiert einmalig definierte Daten. Die Analyse läuft vollständig auf dieser Kopie — ohne Weg zurück ins System.
Was bei „attached” wirklich passiert
Eine Live-Integration bedeutet: Ein Sprachmodell entscheidet zur Laufzeit, welche Aufrufe gegen Ihr System gehen. Daraus folgen vier Risiken, die man kennen sollte:
- Der Agent erbt Berechtigungen. Er agiert mit den Rechten seines Service-Users — und die sind in der Praxis selten minimal geschnitten. Was der User darf, kann auch jeder Fehlgriff des Agenten.
- ADT ist eine Entwicklungsschnittstelle. Sie kann Objekte ändern und Transporte anstoßen. Ein Agent, der „nur mal nachsieht”, hat technisch oft auch den Schreibpfad — und Agentenfehler landen dann nicht im Chatfenster, sondern im System.
- Prompt Injection über Systeminhalte. Alles, was der Agent liest — Kommentare im Code, Tabelleninhalte, Dokumentation — wird Teil seines Kontexts. Präparierte Inhalte können sein Verhalten steuern, mit genau den Berechtigungen aus Punkt 1.
- Datenabfluss ohne klare Grenze. Bei jeder Live-Abfrage entscheidet der Agent ad hoc, welche Geschäftsdaten in den Modellkontext wandern. Was das System wann verlassen hat, ist im Nachhinein schwer zu belegen.
Zur Fairness gehört: Attached-Tooling hat einen legitimen Platz. Für Entwicklerproduktivität im Entwicklungssystem — mit menschlichem Review und eng geschnittenem Scope — ist es ein echter Gewinn. Kritisch wird es, wenn dieselbe Architektur für Analyse und Dokumentation auf produktionsnahen Systemen verwendet wird.
Warum „detached” die robustere Analyse-Architektur ist
Für die Frage „Was tut unser System eigentlich?” braucht die KI keine Verbindung — sie braucht Daten. Und genau da spielt der Extrakt-Ansatz seine Stärken aus:
- Der Scope steht vor der Analyse fest. Sie entscheiden einmal und überprüfbar, welche Daten das System verlassen — nicht der Agent zur Laufzeit.
- Kein Weg zurück. Auf einer Kopie gibt es konstruktionsbedingt keinen Schreibpfad. Selbst ein manipulierter oder fehlgeleiteter Agent kann ein System nicht verändern, zu dem er keine Verbindung hat.
- Auditierbar und reproduzierbar. Der Extrakt ist das vollständige Protokoll dessen, was analysiert wurde. Jede Antwort lässt sich auf diesen Stand zurückführen.
- Kein neues Loch in der Produktionsumgebung. Es muss kein weiteres Tool, kein Service-User und keine offene Schnittstelle am Produktivsystem betrieben werden.
Ein Agent kann nur dort Schaden anrichten, wo er eine Verbindung hat. Ein Extrakt hat keine.
Die eigentliche Entscheidung
Die Frage ist also nicht „KI am SAP: ja oder nein?” — sondern: Welche Aufgabe hat die KI, und welche Architektur passt dazu? Für Code-Assistenz im Entwicklungssystem: attached, mit Review. Für Analyse, Dokumentation und Entscheidungsgrundlagen: detached — mit definiertem Scope und ohne Rückkanal.
Conjola ist konsequent detached gebaut: Sämtliche Analysen — und auch der KI-Assistent, mit dem Sie über Ihr System chatten — arbeiten ausschließlich auf den importierten Extrakten. Es gibt zu keinem Zeitpunkt eine Live-Verbindung in Ihr SAP-System. Die Antworten kommen aus Ihren echten Daten; der Weg zurück existiert nicht.