Lokaler Office Assistent: Datenhoheit braucht Kontrolle
Ein lokaler Office Assistent ist nicht schon deshalb lokal, weil er in Word oder Excel auf dem eigenen Rechner erscheint. Sobald eine Office-Erweiterung, ein sogenanntes Add-in, oder Modell, Ablage, Protokollierung und Updates externe Dienste nutzen, verlässt mindestens ein Teil des Bearbeitungswegs die kontrollierte Umgebung. Datenhoheit entsteht deshalb durch die Architektur des gesamten Systems, nicht durch seine Oberfläche.
Die Lösung passt zu Organisationen, bei denen Prompt, also die Eingabe an das Modell, Quelldaten, interner Modellkontext, also die während einer Aufgabe verarbeiteten Informationen, Ergebnis und erzeugte Dateien vollständig lokal bleiben müssen. Unter den drei verglichenen Optionen bietet sie die höchste Daten- und Modellsouveränität, verlagert aber die gesamte Betriebsverantwortung zum Kunden oder Betreiber. Entscheidend ist der technische Nachweis, dass auch Fehler- und Updatepfade keinen unerlaubten Datenabfluss ermöglichen.
Ein Office Add-in schafft erst dann lokale Datenhoheit, wenn auch Modell, Ablage, Protokolle, Updates und Netzwerkpfade kontrolliert bleiben.
Was macht einen lokalen Office Assistenten wirklich lokal?
Der Benutzer arbeitet in einer lokalen Desktop-Anwendung oder in lokal installiertem Word oder Excel. Die Oberfläche spricht direkt mit einem lokalen Agenten, also einer Software, die Aufgaben steuert, Werkzeuge aufruft und Richtlinien durchsetzt. Dieser Agent greift auf lokale Dokumente, Fachsysteme und ein lokal oder On-Premise, also in der eigenen Infrastruktur, betriebenes Modell zu.
Ein Office Add-in kann dabei die Bedienoberfläche liefern. Es belegt jedoch keine lokale Verarbeitung, wenn Web-Komponenten, Bibliotheken oder das Backend, also der serverseitige Teil der Anwendung, außerhalb der kontrollierten Umgebung laufen. Auch die Office-Integration hängt von Desktop-Anwendung, Add-in und Office-Version ab und kann deshalb mittel bis hoch ausfallen.
Der Modellkontext muss ebenso lokal bleiben wie Prompt, Quellen, Ergebnis und erzeugte Dateien. Externe Modellschnittstellen sind in dieser Architektur nicht vorgesehen. Eine Microsoft-Cloud-Verarbeitung ist nicht erforderlich, wenn Modellbetrieb, Ablage und Netzwerkpfade lokal kontrolliert sind.
Lokale Datenhoheit umfasst den gesamten Datenpfad
Die Systemgrenze muss mehr umfassen als Arbeitsplatz, Office und Modell. Sie schließt Dokumentablage, Zwischenspeicher, temporäre Dateien, Protokolle, Sicherungskopien, Telemetrie, also automatisch erfasste Betriebs- und Nutzungsdaten, sowie Updatewege ein. Cloud-Synchronisierung ist nur mit ausdrücklicher Freigabe zulässig, Metadaten und Telemetrie werden lokal kontrolliert oder technisch unterbunden. Für den Betrieb ergeben sich fünf verbindliche Regeln:
Rohdaten, Quelldaten, Prompts, Ergebnisse und Anhänge werden lokal verarbeitet und nur in genehmigten Speicherorten abgelegt.
Modell und Steuerung bleiben unter eigener Kontrolle, der Modellkontext wird nicht an eine externe Schnittstelle übertragen.
Lokale Protokolle werden minimiert, geschützt und nach einer geregelten Aufbewahrungsfrist gelöscht.
Ausgehende Verbindungen werden standardmäßig gesperrt, ausdrücklich freigegeben und überwacht.
Updates für Office, Add-in und Modell gelangen nur über kontrollierte und rücksetzbare Pfade in die Umgebung.
Die Betriebsverantwortung liegt weitgehend beim Kunden oder Betreiber. Der Softwareanbieter stellt die lokale Office-Software bereit; ohne aktivierte Dienste ist keine Datenverarbeitung durch ihn vorgesehen, und er übernimmt keine operative Verantwortung für Assistent, Add-in, Modellbetrieb oder die lokale Schutzumgebung. Der Betreiber konfiguriert Cloud-Funktionen, wählt Modell und Hardware, verantwortet die Sicherheit und genehmigt Sicherheitsupdates. Entwicklung, Signierung, Verteilung, Richtlinien, Berechtigungen, Sicherungskopien, Aufbewahrung, Löschung, Überwachung, Reaktion auf Sicherheitsvorfälle und Support müssen intern oder durch einen beauftragten Betreiber geregelt werden.
Freigabe braucht überprüfbare Nachweise
Eine Freigabe ist erst konsistent, wenn der gesamte Bearbeitungsweg lokal kontrolliert und der Nichtabfluss technisch belegt ist. Eine installierte Oberfläche ohne kontrolliertes Backend, Modell und Netzwerk genügt nicht. Vor dem Rollout müssen Architektur und Betrieb deshalb gemeinsam geprüft werden.
Ein Architekturplan dokumentiert alle Komponenten, Datenklassen, Datenwege und verbotenen Netzwerkpfade innerhalb der Systemgrenze.
Sicherheitsgrundkonfiguration, Stand der Sicherheitsupdates und Gerätezustand belegen die Härtung von Endpunkt, Betriebssystem und Office; Gerätekontrolle, Schutzsoftware und Rechte nach dem Minimalprinzip begrenzen Malware und überbreite Zugriffe.
Komponentenliste, Netzwerktest, Nachweis des Modellbetriebs und Laufzeittest zeigen, dass Oberfläche, Add-in, Bibliotheken, Backend, Modellausführung und Modellkontext lokal oder ausdrücklich genehmigt sind.
Pfadprüfung und Synchronisierungskonfiguration erfassen Dokumente, Ergebnisse, Zwischenspeicher, temporäre Dateien, Protokolle und Sicherungskopien; Aufbau der Protokolle, Zugriffsrechte, Verschlüsselung und Löschtests begrenzen lokale Rückstände.
Nachweise für Firewall, Vermittlungsserver, also Proxy, und Namensauflösung, kurz DNS, sowie eine Netzwerk-Freigabeliste zeigen, dass ausgehende Verbindungen, Cloud-Funktionen und Telemetrie beschränkt und überwacht werden.
Signaturprüfung, Testumgebung und Rücksetzung sichern Updates; Kapazitätsplanung, Wiederanlauf, Ersatzsysteme und ein Supportprozess begrenzen Betriebsunterbrechungen.
Die Umsetzung beginnt mit Datenklassen, Systemgrenze und Ausschlussliste, danach folgen Endpunkt, lokale KI-Umgebung, technische Kontrollen und der Betriebsnachweis. Der Status bleibt offen, bis alle Muss-Kriterien auch unter Normal-, Fehler- und Updatebedingungen erfüllt sind. Management, Datenschutz, Informationssicherheit, Fachbereich, IT-Betrieb und KI-Governance verantworten die Freigabe.
Welche Aufgaben eignen sich für lokale KI in Office?
Geeignete Anwendungsfälle haben gemeinsam, dass schon die Übertragung von Dokument, Prompt, Ergebnis oder Bearbeitungskontext an einen Cloud-Dienst unzulässig ist. Die lokale Architektur muss dabei den gesamten Bearbeitungsweg einschließlich temporärer Dateien und Protokolle abdecken.
Sensible Verträge lassen sich lokal prüfen, zusammenfassen oder auf Klauseln analysieren, wenn Dokument, Prompt, Analyse und Ergebnis die Umgebung nicht verlassen.
Bei Personalakten kann der Assistent Suche, Strukturierung und Auswertung unterstützen, ohne personenbezogene Inhalte an externe KI- oder Cloud-Dienste zu übertragen.
Medizinische Dokumente können lokal extrahiert, klassifiziert oder für Entwürfe genutzt werden, wenn Gesundheitsdaten und Bearbeitungskontext lokal bleiben.
Geschäftsgeheimnisse lassen sich lokal analysieren, sofern Modelle, Protokolle, Dateipfade und Netzwerkzugriffe kontrolliert sind.
Vertrauliche Excel-Analysen können Formelhilfe, Datenprüfung und Zusammenfassungen nutzen, wenn Arbeitsmappe, Zwischenergebnisse und Ausgabedateien lokal bleiben.
Der Schutzbedarf bestimmt damit die Architektur, nicht die Bequemlichkeit der Oberfläche. Entscheidend ist nicht, ob eine Aufgabe in Office beginnt, sondern ob jeder Verarbeitungsschritt die genehmigte Umgebung einhält.
Wo es nicht hilft
Die lokale Lösung bringt wenig, wenn eine genehmigte Cloud-Architektur den fachlichen Bedarf bereits erfüllt. Ihr Implementierungsaufwand ist hoch bis sehr hoch, weil Endpunkte, Modelle, Updates, Netzwerk, Überwachung und Support dauerhaft betrieben werden müssen. Fehlen dafür klare Zuständigkeiten oder technische Kontrollen, entsteht keine belastbare Datenhoheit.
Ist Microsoft-Cloud-Verarbeitung zulässig und deckt Standard-Copilot den Bedarf, ist Option 1 einfacher.
Darf eine minimierte Interaktion in Microsoft 365 gespeichert werden, während Rohdaten, Modell und interner Kontext lokal bleiben, sollte Option 2 geprüft werden.
Verwendet das Add-in ein externes Web-Backend, eine externe Modellschnittstelle oder externe Überwachung, passt die Architektur nicht zur behaupteten Lokalität.
Lassen sich Cloud-Synchronisierung, Telemetrie oder ausgehende Netzwerkpfade nicht ausreichend beschränken und überwachen, fehlt eine zentrale Voraussetzung.
Kann die Organisation Endpunkte, Modelle, Sicherheitsupdates, Überwachung und Support nicht dauerhaft selbst betreiben, ist die Lösung nicht passend.
Die Grenze verläuft also nicht zwischen Desktop und Cloud, sondern zwischen kontrollierten und unkontrollierten Datenwegen. Ein lokales Office-Programm beweist so wenig wie ein lokal sichtbares Add-in, solange Zwischenspeicher, Protokolle, Updates oder Backends außerhalb der Kontrolle liegen.
Der Lokalitätsnachweis muss Fehler und Updates einschließen
Ein erster Lokalitätsnachweis kann mit synthetischen Dokumenten und einem eindeutigen Schutzmarker erfolgen. Der Marker macht sichtbar, ob Dokumentinhalt, Prompt oder Ergebnis in einem ausgehenden Datenstrom auftauchen. Der Test prüft Verarbeitung, Speicherung und Protokollierung ebenso wie Fehler-, Neustart- und Updatepfade.
Ein isolierter Testarbeitsplatz wird mit lokalem Word oder Excel, lokaler Assistentenoberfläche, lokalem Agenten und lokalem Modell bereitgestellt.
Cloud-Synchronisierung, externe Modellschnittstellen und nicht benötigte Office-Cloud-Funktionen werden deaktiviert; ausgehende Verbindungen werden am Endpunkt und Netzübergang protokolliert.
Ein synthetisches Dokument mit Schutzmarker wird lokal analysiert, Ergebnis und erzeugte Datei werden ausschließlich lokal gespeichert.
Netzwerk-, DNS-, Proxy- und Telemetrieprotokolle werden darauf geprüft, dass Schutzmarker, Prompt, Dokumentinhalt und Ergebnis in keinem ausgehenden Datenstrom erscheinen.
Zwischenspeicher, temporäre Dateien, Protokolle, Sicherungskopien und Wiederherstellungspunkte werden kontrolliert, anschließend wird die definierte Löschung getestet.
Ein Update für Add-in oder Modell sowie Fehlerfall und Neustart werden simuliert; nur signierte Pakete dürfen die Grenze passieren, Nutzdaten dürfen den Updatepfad nicht nutzen. Anschließend werden die Prozesse gestoppt und Architektur, Messergebnisse, Abweichungen und Restrisiken dokumentiert.
Dieser synthetische Test belegt keinen vollständigen Produktionsschutz. Lieferkette, Schwachstellenmanagement, Hardwareausfall, Insider-Risiken, Skalierung und langfristiger Support müssen im Betrieb separat bewertet werden. Vor dem Rollout bleibt deshalb eine Frage: Kann die Organisation die lokale Kontrollkette nicht nur aufbauen, sondern dauerhaft betreiben und nachweisen?
Verbindungen
Offenlegung: Lukas Sparer PhD
