Custom Engine Agent: Datensouveränität bleibt partiell
Ein Custom Engine Agent, also ein kundenseitig kontrollierter KI-Agent im Microsoft-365-Kanal, verbindet Teams oder Copilot mit einem eigenen Modell, lokaler Fachlogik und lokalen Systemen. Das löst kein Entweder-oder zwischen Cloud und lokaler Verarbeitung. Es schafft Modellkontrolle, aber nur partielle und architekturabhängige Datensouveränität, also begrenzte Kontrolle darüber, wo Daten verarbeitet und gespeichert werden.
Der Ansatz passt, wenn die freigegebene Interaktion in Microsoft 365 liegen darf, vertrauliche Rohdaten und interner Modellkontext aber lokal bleiben sollen. Belastbar wird die Entscheidung erst, wenn genau feststeht, welche Prompts, Ergebnisse, Dateien und Metadaten die lokale Grenze verlassen dürfen und wie sich die Minimierung der Ausgabe technisch nachweisen lässt.
Ein Custom Engine Agent schafft partielle Datensouveränität, aber keine vollständig lokale Architektur.
Wie funktioniert ein Custom Engine Agent?
Teams oder Copilot bildet den Benutzerkanal. Der kundenseitig kontrollierte Agent verarbeitet die freigegebene Anfrage, greift lokal auf Modelle und Systeme zu und gibt nur das freigegebene Ergebnis an Microsoft 365 zurück. Der sichtbare Kanal bleibt mit seinen Metadaten in Microsoft 365.
Rohdaten, Quelldaten und der interne Modellkontext können vollständig in der lokalen Umgebung bleiben, sofern sie nicht als Prompt, Anhang oder Datei übertragen werden. Auch Modell und Hosting sowie lokale Agentenlogs und Zwischendaten lassen sich nach eigener Richtlinie kundenseitig kontrollieren. Microsoft 365 verarbeitet und speichert dagegen den freigegebenen Prompt, das minimierte Ergebnis, Chatverlauf und Interaktionsmetadaten sowie ausdrücklich freigegebene Dateien.
Die Office-Integration ist im Chat- und Agentenkanal hoch, entspricht aber nicht in jeder Funktion dem nativen Copilot. Der Implementierungsaufwand ist hoch. Zentrale Kontrollpunkte sind die lokale Verarbeitungsgrenze, Ausgabeminimierung, Identität, Kanalberechtigungen, Speicherung und Retention, also die Regeln für die Aufbewahrungsdauer.
Der Übertragungsvertrag entscheidet über Datensouveränität
Die Architektur braucht zwei abgestimmte Kontrollsysteme. Microsoft 365 steuert den Benutzerkanal, der Kunde die lokale Verarbeitungsumgebung. Der Übergang dazwischen ist ein eigener Sicherheits- und Freigabepunkt, nicht nur eine technische Schnittstelle.
Der Übertragungsvertrag legt für Prompt, Ergebnis, Dateien und Metadaten fest, was Microsoft 365 erreichen darf. Als Nachweis dienen Feldliste, Datenfluss und genehmigte Beispiele.
Die lokale Datengrenze wird mit Marker-Test, Netzwerkprüfung und Dateipfadkontrolle geprüft. Regeln, Testfälle und Freigabelogik belegen die Ausgabeminimierung.
Microsoft-365-Identität und lokale Berechtigung müssen eindeutig verbunden sein. Identitätsfluss, Autorisierungstest, Kanalrichtlinien und technische Sperren verhindern falsche Rechte sowie unzulässige Uploads und Rückgaben.
Zugangsschlüssel und andere Secrets gehören weder in Code noch in Logs. Ein Secret-Konzept, eine Netzwerk-Allowlist mit erlaubten Zielen und ein Egress-Protokoll begrenzen ausgehende Verbindungen.
Lokale Logs dürfen keine Rohdaten, Prompts oder Secrets enthalten und müssen vom Microsoft-365-Verlauf getrennt behandelt werden. Logschema, Aufbewahrung und Löschtest liefern den Nachweis.
Ein reproduzierbares Testprotokoll muss Datenfluss und Nichtübertragung lokaler Inhalte belegen und als Freigabenachweis dienen.
Microsoft verantwortet Verarbeitung und Speicherung der freigegebenen Interaktion, die Agentenschnittstelle und den Betrieb des Cloud-Kanals. Der Kunde verantwortet Kanalzulässigkeit, Berechtigungen, Retention, Audit, Agentenlogik, Richtlinien und Ausgabeminimierung sowie Auswahl, Hosting, Updates, Sicherheit und Monitoring des eigenen Modells. Hinzu kommen Zugriff, Klassifizierung und Isolation lokaler Daten sowie Integration, Fehlerbehandlung, Support und Gesamtrisiko des Betriebs.
Diese Anwendungsfälle passen
Der Ansatz unterstützt zwei Architekturpfade. Cloudfähige Daten lassen sich mit einem eigenen Modell oder besonderer Fachlogik verarbeiten. Nicht cloudfähige Rohdaten bleiben lokal, wenn nur ein abgeleitetes, minimiertes und freigegebenes Ergebnis an Microsoft 365 geht.
Abfragen lokaler Systeme für Enterprise Resource Planning, kurz ERP, liefern benötigte Ergebnisse über den vertrauten Microsoft-365-Kanal, ohne die berechtigten Quelldaten zu übertragen.
Produktionsassistenten für Operational Technology, kurz OT, halten OT-Daten, Prozesskontext und Zwischenwerte lokal und geben fachliche Status- oder Handlungshinweise aus.
Spezialisierte Fachmodelle oder eine eigene Orchestrierung werden über Teams oder Copilot zugänglich, wenn sie fachlich erforderlich sind.
Lokale Analysen geben nur Zusammenfassungen oder Statusmeldungen aus, nicht die zugrunde liegenden Rohdaten.
Cloudfähige Daten können mit eigenen Regeln und Werkzeugen im vorhandenen Kanal verarbeitet werden, wenn Standard-Copilot funktional nicht ausreicht.
Risiken brauchen technische Gegenmaßnahmen
Die Risiken entstehen vor allem an der Grenze zwischen lokaler Verarbeitung und Cloud-Kanal. Wirksame Gegenmaßnahmen müssen nicht nur dokumentiert, sondern mit Normalfällen, Fehlerfällen und unzulässigen Anfragen getestet werden.
Rohdaten im Kanal: Kanalregeln, technische Sperren, Nutzerführung und Testfälle verhindern, dass lokale Inhalte als Prompt, Anhang oder Datei übertragen werden.
Unzureichend minimierte Antworten: Freigabefilter, strukturierte Ausgaben, Marker-Tests und Negativtests suchen nach Rohdaten, Schutzmarkern und internem Modellkontext.
Fehlerhafte Identitätsabbildung: Eine durchgängige Identität, minimale Rechte und Autorisierungstests verhindern zu breite Rechte und verwechselte Benutzerkontexte.
Doppelte Speicherung: Getrennte Logschemas, Retention und Inhaltsminimierung begrenzen Daten in lokalen Logs und im Microsoft-365-Verlauf.
Unkontrollierte Ausgangsverbindungen: Netzwerk-Allowlist, Proxy-Kontrolle, Monitoring und Freigabeprozess begrenzen Tools, Updates und Modellendpunkte auf genehmigte Ziele.
Falsche Souveränitätsannahme: Datenflussdokumentation und die klare Benennung der Microsoft-365-Interaktion verhindern, dass die Architektur als vollständig lokal dargestellt wird.
Wie lässt sich die Architektur vor dem Rollout prüfen?
Die Umsetzung folgt fünf Phasen: Der Vertrag definiert zulässige Eingaben, Ausgaben, Dateien und Metadaten. Danach entstehen die kontrollierte lokale Verarbeitungsgrenze, die begrenzte Integration der Microsoft-365-Identität und Agentenschnittstelle, ein Prüfprotokoll mit Restrisiken sowie ein Betriebsmodell mit Monitoring, Updates, Freigaben, Support und Reviewkalender. Ein erster Machbarkeitsnachweis kommt ohne Kundendaten, Retrieval Augmented Generation, kurz RAG, also ohne die Ergänzung von Anfragen durch abgerufene Wissensquellen, und ohne Produktivzugriffe aus; er ersetzt aber keine Datenschutz- oder Produktionsfreigabe.
Einen lokalen oder On-Prem-Modellendpunkt verwenden. Ein externer Cloud-Endpunkt ist nur mit vollständig synthetischen Daten zulässig.
Einen minimalen TypeScript-Agenten auf localhost:3978 mit dem Pfad /api/messages bereitstellen. Base URL, API-Key und Modell werden ausschließlich über Umgebungsvariablen konfiguriert.
Den Agenten lokal mit dem Microsoft 365 Agents Playground verbinden. Für diesen Test sind weder Tunnel noch Teams-Sideloading erforderlich.
Einen synthetischen Marker senden und die unveränderte Modellantwort prüfen. Die Logs enthalten nur Zeitstempel und die Ereignisse request received, model started, model finished und response sent.
Für die Vertiefung eine lokale synthetische Quelldatei mit eindeutigem Schutzmarker verwenden. Der Agent darf nur eine abgeleitete Statusmeldung an den Microsoft-Kanal zurückgeben.
Mit Inhalts- und Netzwerkprüfung belegen, dass Quelldatei, Schutzmarker und interner Modellkontext lokal geblieben sind. Danach die Prozesse stoppen und Ergebnis sowie Grenzen dokumentieren.
Die Vorlage führt acht Muss-Kriterien, deren Status offen ist. Sie betreffen die Zulässigkeit der Microsoft-365-Speicherung, den tatsächlichen Bedarf für Modell oder lokale Komponenten, den Verbleib von Rohdaten und Modellkontext, einen durchsetzbaren Übertragungsvertrag, funktionierende Identität und Autorisierung, kontrollierte Secrets, Logs, Zwischendaten und Egress-Pfade, geregelte Kanalberechtigungen, Speicherung, Retention und Audit sowie die dauerhafte Betriebsübernahme durch den Kunden. Eine Freigabe ist erst konsistent, wenn alle Kriterien erfüllt und der Datenfluss mit Positiv- und Negativtests nachgewiesen ist; verantwortlich sind Management, Datenschutz, Informationssicherheit, Fachbereich und KI Governance.
Grenzen: Wo der Ansatz nicht hilft
Der Ansatz ist keine vollständig lokale Lösung. Seine Grenzen sind erreicht, sobald die freigegebene Interaktion nicht in der Microsoft-Cloud liegen darf oder die lokale Kontrolle praktisch nicht nachweisbar ist.
Dürfen auch freigegebener Prompt, Ergebnis, erzeugte Dateien und Metadaten keine Microsoft-Cloud-Dienste erreichen, ist Option 3 zu prüfen.
Deckt Standard-Copilot den fachlichen Bedarf ab und sind alle Daten für Microsoft 365 genehmigt, ist Option 1 einfacher.
Lassen sich lokale Verarbeitungsgrenze oder Ausgabeminimierung nicht technisch prüfen, fehlt die Freigabegrundlage.
Müssen Benutzer regelmäßig Rohdaten oder nicht freigegebene Dateien in den Microsoft-365-Kanal laden, passt die Architektur nicht.
Kann die Organisation Modell, Agent, Schnittstellen, Logs und Sicherheitsupdates nicht dauerhaft betreiben, ist der Ansatz nicht tragfähig.
Auch der lokale Playground-Test hat enge Grenzen. Er belegt weder eine echte Teams- oder Copilot-Integration noch reale Microsoft-Speicherpfade, Dateiwege, Single Sign-on als durchgängige Anmeldung, die Trennung verschiedener Mandanten, wirksame Produktionsisolation oder eine Datenschutzfreigabe; diese Punkte brauchen getrennte Freigabestufen.
Damit hängt die Entscheidung nicht am Produktnamen, sondern am überprüfbaren Datenfluss und an dauerhaft geklärten Betriebsverantwortungen. Bleibt ein Muss-Kriterium offen, darf der Rollout nicht freigegeben werden. Die entscheidende Frage lautet deshalb: Kann die Organisation für jede Datenklasse nachweisen, wo sie verarbeitet, gespeichert und gelöscht wird?
Verbindungen
Offenlegung: Alexander Neulinger PhD
