Viele Unternehmen haben in den vergangenen Monaten erste KI-Piloten im Backoffice aufgesetzt: Dokumente vorsortieren, Inhalte für das Content-Management-System vorbereiten, Daten aus dem ERP-System zusammenfassen. In der Pilotphase funktioniert das oft überzeugend. Der Übergang in den produktiven Betrieb verläuft deutlich holpriger — und zwar seltener aus fachlichen, häufiger aus architektonischen Gründen.

Zwei aktuelle Fachbeiträge setzen genau hier an. Ein Hintergrundartikel bei heise developer argumentiert, dass sich KI-Agenten nur dann sicher in bestehende Systeme einbinden lassen, wenn die Architektur eine Trennung von Daten und Handlungen vorsieht. Ein Beitrag auf Golem.de — gekennzeichnet als Anzeige der Telekom — beschreibt die andere Seite derselben Medaille: Piloten überzeugen, im produktiven Betrieb entstehen jedoch neue Risiken, und über den Erfolg entscheiden Infrastruktur, Security und Datenkontrolle.

Warum Daten und Handlungen getrennt gehören

Ein KI-Agent ist kein reiner Textgenerator, sondern ein System, das auf Basis von Eingaben eigenständig Schritte ausführt: Dateien lesen, Datensätze abfragen, Inhalte schreiben, Schnittstellen aufrufen. Sobald diese beiden Rollen — Informationen verarbeiten und Aktionen auslösen — in derselben Verarbeitungsschicht zusammenfallen, wird jede eingelesene Information potenziell zur Anweisung.

Das ist der Kern des Arguments: Ein Agent, der eine Kunden-E-Mail, ein PDF oder einen Datenbankeintrag liest, kann nicht zuverlässig unterscheiden, ob darin enthaltener Text zu den Nutzdaten oder zu seinen Instruktionen gehört. Trennt die Architektur beides sauber, lässt sich diese Vermischung technisch begrenzen, statt sie nur durch Formulierungen im Prompt — also in der Anweisung an das Modell — zu entschärfen.

Praktisch heißt das: Handlungen laufen über definierte, eng geschnittene Schnittstellen, nicht über freie Interpretationen des Modells. Welche Operation ein Agent überhaupt auslösen darf, wird außerhalb des Modells festgelegt und durchgesetzt.

Der Pilot verdeckt die eigentlichen Fragen

In einem Pilotprojekt sind die Rahmenbedingungen komfortabel: wenige Nutzerinnen und Nutzer, überschaubare Datenmengen, ein eingeweihtes Team, das Ergebnisse ohnehin prüft. Fehler fallen auf, bevor sie Wirkung entfalten. Genau diese Schutzschicht fällt im Regelbetrieb weg.

Der Golem-Beitrag benennt die Verschiebung: Mit der Skalierung treten Risiken auf, die im Pilotbetrieb keine Rolle spielten. Infrastruktur, Security und Datenkontrolle rücken damit von der Nebenbedingung in die Hauptrolle. Beide Quellen laufen auf denselben Punkt zu, nähern sich ihm aber aus unterschiedlichen Richtungen: der eine Beitrag vom Entwurf der Agenten-Architektur her, der andere vom Betrieb und der Absicherung her.

Einordnend lohnt der Hinweis, dass der Golem-Text als Anzeige eines Anbieters erschienen ist. Die beschriebene Problemlage deckt sich dennoch mit der technischen Argumentation des heise-Beitrags — die Übereinstimmung liegt in der Diagnose, nicht in einer bestimmten Produktempfehlung.

Typische Bruchstellen bei der Anbindung an CMS und ERP

Wer Agenten an bestehende Systeme koppelt, trifft in der Praxis auf wiederkehrende Fragen:

  • Rechte: Mit welcher Identität handelt der Agent? Erbt er die Rechte der aufrufenden Person oder arbeitet er mit einem eigenen, dauerhaft weit gefassten Zugang?
  • Datenzugriff: Welche Teilmenge der Inhalte braucht der Agent tatsächlich — und wie wird verhindert, dass er darüber hinaus liest?
  • Schreibende Operationen: Welche Änderungen darf er direkt ausführen, welche erzeugen nur einen Entwurf zur Freigabe?
  • Nachvollziehbarkeit: Lässt sich im Nachhinein rekonstruieren, welche Eingabe zu welcher Aktion geführt hat?
  • Fehlverhalten: Wie wird ein Agent gestoppt, wenn er im laufenden Betrieb unerwartete Ergebnisse liefert?

Keine dieser Fragen ist neu. Sie sind aus der Integration klassischer Drittsysteme bekannt. Neu ist, dass die handelnde Komponente nicht deterministisch arbeitet — also bei gleicher Ausgangslage nicht zwingend dasselbe tut. Das verschiebt das Gewicht von der Prüfung des Ergebnisses hin zur Begrenzung dessen, was überhaupt möglich ist.

Ein pragmatischer Aufbau

Aus den beschriebenen Anforderungen lässt sich ein nüchternes Vorgehen ableiten:

  1. Anwendungsfall eng schneiden. Ein Agent mit drei klar definierten Operationen ist leichter abzusichern als ein universeller Assistent.
  2. Aktionen als explizite Schnittstellen definieren. Jede Operation wird im Vorfeld beschrieben, inklusive erlaubter Parameter und Wertebereiche.
  3. Rechte minimal vergeben. Der Agent erhält nur Zugriff auf die Daten und Funktionen, die der konkrete Prozess benötigt.
  4. Freigabeschritte einbauen, wo Wirkung nach außen entsteht. Veröffentlichte Inhalte, Bestellungen oder Kundenkommunikation vertragen einen Zwischenschritt.
  5. Protokollieren. Eingaben, ausgelöste Aktionen und Ergebnisse gehören in ein auswertbares Log.
  6. Betrieb mitplanen. Infrastruktur, Monitoring und Zuständigkeiten werden nicht nachgereicht, sondern gehören in den Entwurf.

Organisation statt reiner Technik

Ein Teil der Skalierungsprobleme liegt außerhalb der Software. Wenn im Pilotprojekt ein engagiertes Team die Ergebnisse kontrolliert, ist unklar, wer das im Regelbetrieb tut. Verantwortlichkeiten für Freigaben, für die Pflege der Datenbasis und für die Reaktion auf Auffälligkeiten müssen benannt sein, bevor ein Agent produktiv geht.

Hilfreich ist, den Agenten nicht als eigenständiges Projekt zu betrachten, sondern als weitere Komponente in einer bestehenden Systemlandschaft — mit denselben Anforderungen an Betrieb, Rechteverwaltung und Dokumentation, die auch für andere Integrationen gelten.

Was das für Web- und Softwareprojekte heißt

Für Projekte rund um TYPO3, ERP-Anbindungen und interne Fachanwendungen verschiebt sich der Aufwand nach vorn: Die Frage, welche Handlungen ein Agent über welche Schnittstelle ausführen darf, gehört in die Konzeptphase und nicht in die Abnahme. Wer Daten und Handlungen von Beginn an trennt, kann Anwendungsfälle später erweitern, ohne die Sicherheitsarchitektur jedes Mal neu aufzurollen. Piloten bleiben sinnvoll — sie sollten aber von Anfang an auf der Infrastruktur aufsetzen, auf der später auch der Produktivbetrieb laufen soll.

Quellen