Für vertrauliche Firmendaten eignen sich vor allem drei Betriebsmodelle: eine vollständig lokale KI im eigenen Netz, eine verwaltete Unternehmensplattform mit abgeschotteten Endpunkten oder eine in bestehende Microsoft-365-Berechtigungen eingebundene KI. Entscheidend ist nicht allein der Produktname, sondern ob Eingaben gespeichert, zum Training verwendet, an Unterauftragnehmer übertragen oder außerhalb der vorgesehenen Region verarbeitet werden. Unternehmen sollten daher zuerst Datenklassen und zulässige Betriebsorte festlegen und erst danach eine Lösung auswählen.
Unter Windows reicht die Spanne von Ollama oder llama.cpp auf einem einzelnen Rechner bis zu zentral betriebenen Plattformen wie Azure AI Foundry beziehungsweise Azure OpenAI, Microsoft 365 Copilot, NVIDIA NIM oder vLLM. Keine dieser Lösungen ist allein durch die Bezeichnung „privat“ automatisch für Geschäftsgeheimnisse geeignet. Identitäten, Netzwerkgrenzen, Protokolle, angebundene Datenquellen und Administrationsrechte bestimmen, wie vertraulich der tatsächliche Betrieb ist.
Welche Lösungen für welche Vertraulichkeitsstufe passen
Die folgende Einordnung vergleicht die Kandidaten nach demselben Raster: Betriebsort, Kontrolle über das Modell, Einbindung vorhandener Berechtigungen, Verwaltungsaufwand und typische Grenze. Die Kategorien sind wichtiger als eine scheinbare Bestenliste, weil eine lokale Entwicklungsabteilung andere Anforderungen hat als ein Unternehmen, das bereits Dokumente und Identitäten in Microsoft 365 verwaltet.
- Ollama mit Open WebUI: geeignet für lokale Pilotprojekte, interne Chatoberflächen und ausgewählte offene Modelle. Modell und Oberfläche können auf eigener Hardware laufen. Das Unternehmen kontrolliert den Rechner und die gespeicherten Daten, muss aber Benutzerverwaltung, Updates, Protokollierung, Sicherungen und die Absicherung von Open WebUI selbst organisieren.
- llama.cpp: geeignet für besonders schlanke lokale Ausführungen und individuell entwickelte Anwendungen. Die Software kann quantisierte Modelle auch ohne einen umfangreichen Plattformaufbau ausführen. Komfortfunktionen für Rollen, Freigaben und revisionsfähige Verwaltung gehören jedoch nicht automatisch dazu.
- vLLM: geeignet für einen zentralen, leistungsfähigen Inferenzdienst mit kompatibler API, meist auf Linux-Servern mit geeigneten GPUs. Windows-Arbeitsplätze können diesen Dienst über das Firmennetz nutzen. Für einen reinen Windows-Server-Betrieb ist vLLM nicht die naheliegendste Standardwahl; eine Linux-Serverumgebung ist in der Regel der sauberere Betriebsrahmen.
- LocalAI: geeignet, wenn Anwendungen eine lokal bereitgestellte, OpenAI-kompatible Schnittstelle ansprechen sollen. Das erleichtert die Umstellung vorhandener Software. Sicherheit, Modellqualität und Mehrbenutzerbetrieb hängen von der selbst aufgebauten Umgebung ab.
- NVIDIA NIM: geeignet für Unternehmen, die KI-Dienste containerisiert in einer kontrollierten Infrastruktur bereitstellen und dafür passende NVIDIA-Hardware sowie eine betriebliche Containerplattform besitzen. Der Ansatz bietet mehr Plattformstruktur als ein einzelner Desktop-Dienst, verlangt aber Infrastruktur-, Lizenz- und GPU-Planung.
- Azure AI Foundry und Azure OpenAI: geeignet, wenn ein verwalteter Cloud-Dienst, zentrale Identitäten und private Netzwerkpfade benötigt werden. Private Endpunkte, Rollen und regionale Bereitstellung können eine abgeschottete Architektur unterstützen. Ob ein bestimmtes Modell in der gewünschten Region und mit den benötigten Bedingungen verfügbar ist, muss vor der Freigabe im Azure-Portal und in den Vertragsunterlagen geprüft werden.
- Microsoft 365 Copilot: geeignet, wenn die KI innerhalb der Microsoft-365-Arbeitsumgebung auf Inhalte zugreifen soll, für die der jeweilige Benutzer bereits berechtigt ist. Die Stärke liegt in der Einbindung von Identitäten, Richtlinien und Microsoft-365-Daten. Zu weit gefasste SharePoint-, Teams- oder OneDrive-Berechtigungen werden dadurch jedoch nicht repariert, sondern können bei Such- und Antwortvorgängen sichtbar werden.
Ein universeller Sieger lässt sich aus diesen Unterschieden nicht ableiten. Für streng isolierte Entwicklungsdaten ist ein lokaler Dienst ohne ausgehende Verbindung häufig leichter abzugrenzen. Für mehrere Abteilungen mit zentraler Anmeldung, Protokollierung und geregeltem Lebenszyklus kann eine verwaltete Plattform die bessere Kontrolle bieten, obwohl sie nicht im eigenen Serverraum läuft.
„Lokal“ und „privat“ bedeuten nicht dasselbe
Eine KI ist lokal, wenn Modell und Inferenz auf eigener Hardware ausgeführt werden. Privat ist der Gesamtprozess erst, wenn auch Oberfläche, Dokumentenspeicher, Protokolle, Sicherungen und Hilfsdienste innerhalb der festgelegten Vertrauensgrenze bleiben. Eine lokale Chatoberfläche kann beispielsweise trotzdem externe Modell-Downloads abrufen, Telemetrie übertragen oder über Erweiterungen Internetdienste ansprechen.
Umgekehrt kann ein Cloud-Dienst eine kontrollierte Unternehmenslösung sein, wenn vertragliche Verarbeitung, Mandantentrennung, Identitätsverwaltung, Aufbewahrung und Netzwerkzugriff zu den eigenen Vorgaben passen. „Cloud“ bedeutet also nicht automatisch öffentlich; „On-Premises“ garantiert nicht automatisch Schutz.
Besonders wichtig ist die Unterscheidung zwischen Training und Inferenz. Bei der Inferenz verarbeitet das Modell eine Eingabe und erzeugt eine Antwort. Beim Training oder einer Feinabstimmung werden Modellparameter verändert. Die Aussage, dass Kundeneingaben nicht zum Training eines Basismodells verwendet werden, beantwortet noch nicht, wie lange Prompts, Antworten, Missbrauchsprotokolle oder hochgeladene Dateien gespeichert bleiben. Diese Punkte müssen einzeln geprüft werden.
Entscheidungsweg vor der Produktauswahl
- Daten einordnen: Trenne mindestens öffentliche, interne, vertrauliche und besonders geschützte Inhalte. Zugangsdaten, private Schlüssel und produktive Geheimnisse sollten nicht allein durch eine allgemeine KI-Freigabe legitimiert werden.
- Betriebsgrenze festlegen: Entscheide, ob Verarbeitung nur auf einem einzelnen Windows-PC, im internen Rechenzentrum, in einer bestimmten Cloud-Region oder innerhalb eines genehmigten Mandanten stattfinden darf.
- Zugriffsmodell bestimmen: Lege fest, ob die KI nur manuell eingefügte Texte erhält oder auf SharePoint, Dateifreigaben, Datenbanken und Fachsysteme zugreifen darf. Ein lesender Zugriff ist nicht risikofrei, weil die Antwort Inhalte aus mehreren Quellen zusammenführen kann.
- Anbieterangaben getrennt prüfen: Relevant sind Trainingsnutzung, Speicherung, Aufbewahrungsdauer, Regionen, Unterauftragnehmer, Verschlüsselung, Löschung, Administrationszugriffe und Protokollierung. Eine allgemeine Datenschutzseite ersetzt keine Prüfung des gebuchten Unternehmensprodukts.
- Pilot begrenzen: Starte mit synthetischen oder freigegebenen Daten, einer kleinen Benutzergruppe und deaktivierten Erweiterungen. Erst nach der Auswertung der Protokolle sollten echte vertrauliche Quellen angebunden werden.
- Abbruch und Löschung testen: Vor dem Produktivbetrieb muss geklärt sein, wie Zugriffe entzogen, Indizes gelöscht, Schlüssel gewechselt und gespeicherte Unterhaltungen entfernt werden.
Lokale KI auf Windows richtig einordnen
Ollama und llama.cpp ermöglichen einen schnellen Einstieg auf Windows-Arbeitsplätzen. Das ist sinnvoll, wenn wenige Personen mit überschaubaren Modellen arbeiten und die Daten den Rechner nicht verlassen sollen. Für einen belastbaren Unternehmensdienst genügt die Installation auf einem leistungsfähigen PC jedoch nicht.
Der Rechner braucht eine definierte Zuständigkeit für Windows-Updates, Grafiktreiber, Modellversionen und Sicherheitsvorfälle. Die lokale API darf nicht ungeprüft an alle Netzwerkschnittstellen gebunden werden. Wird eine Weboberfläche ergänzt, benötigt sie eine verlässliche Anmeldung, verschlüsselte Übertragung und rollenbasierte Freigaben. Außerdem muss feststehen, wo Chatverläufe und hochgeladene Dateien gespeichert werden.
WSL 2 kann Linux-Werkzeuge auf Windows nutzbar machen, erzeugt aber eine zusätzliche Systemgrenze. Administratoren müssen dann sowohl Windows als auch die Linux-Distribution, deren Pakete, virtuelle Datenträger und Netzwerkfreigaben berücksichtigen. Ein Dienst in WSL 2 ist nicht allein deshalb vom übrigen Netz isoliert. Für einen dauerhaft verfügbaren Mehrbenutzerdienst ist ein verwalteter Linux-Server oder eine Containerplattform oft nachvollziehbarer als eine Entwicklerinstallation auf einem Arbeitsplatzrechner.
Auch die Modelldatei verdient Aufmerksamkeit. Offene Gewichte können lokal ausgeführt werden, enthalten aber keine automatische Garantie für Qualität, Lizenzverträglichkeit oder Freiheit von unerwünschtem Verhalten. Vor dem Einsatz sind Herkunft, Lizenz, Prüfsumme, Modellkarte und interne Freigabe zu dokumentieren. Modelle sollten nur aus genehmigten Repositories bezogen und nicht von einzelnen Beschäftigten unkontrolliert ausgetauscht werden.
Microsoft-Plattformen: Berechtigungen sind die eigentliche Grenze
Bei Microsoft 365 Copilot entscheidet die bestehende Rechtearchitektur wesentlich darüber, welche Unternehmensinformationen ein Benutzer über die KI erreichen kann. Eine Datei, die wegen einer zu offenen SharePoint-Gruppe bereits lesbar ist, wird durch die KI nicht vertraulicher. Vor einer breiten Einführung sollten Administratoren externe Freigaben, organisationsweite Gruppen, vererbte Websiteberechtigungen und veraltete Teams prüfen.
Für die technische Kontrolle sind insbesondere das Microsoft-365-Admin-Center, das Microsoft-Purview-Portal und die Entra-Verwaltung relevant. Dort lassen sich je nach Lizenz und Umgebung Identitäten, Zugriffe, Aufbewahrung, Informationsschutz und Überwachung verwalten. Welche Copilot-Funktionen tatsächlich eingeschlossen sind, muss anhand des gebuchten Produkts und der im Mandanten sichtbaren Administrationsseiten geprüft werden; ähnlich benannte Consumer- und Unternehmensangebote dürfen nicht gleichgesetzt werden.
Azure AI Foundry beziehungsweise Azure OpenAI passt besser, wenn eine eigene Anwendung ein Modell aufrufen soll. Eine geschützte Architektur verwendet nach Möglichkeit verwaltete Identitäten statt fest eingebauter API-Schlüssel, beschränkt Rollen auf die benötigten Ressourcen und führt den Datenverkehr über genehmigte Netzwerkpfade. Ein privater Endpunkt reduziert die öffentliche Erreichbarkeit, löst aber keine Fehler in der Anwendung: Prompts können weiterhin in Anwendungsprotokollen, Diagnoseplattformen oder Datenbanken landen.
Vor der Freigabe sollten im Azure-Portal die Bereitstellungsregion, das gewählte Modell, Netzwerkzugriff, Identitätsrollen, Diagnoseeinstellungen und verbundene Speicherdienste kontrolliert werden. Produktbedingungen und Datenverarbeitungsunterlagen müssen zur tatsächlich eingesetzten Azure-Ressource passen, nicht nur allgemein zu Microsoft.
RAG schützt Daten nicht automatisch
Retrieval-Augmented Generation, kurz RAG, ergänzt eine Anfrage um passende Ausschnitte aus internen Dokumenten. Das Modell muss dabei nicht mit den Firmendokumenten trainiert werden. Trotzdem entstehen mehrere schützenswerte Bestandteile: Originaldateien, extrahierter Text, Suchindex, Vektorrepräsentationen, Abfrageprotokolle und die erzeugte Antwort.
Die Zugriffskontrolle muss vor dem Abruf greifen. Es reicht nicht, nur die Chatoberfläche abzusichern und einen gemeinsamen Index für alle Beschäftigten zu verwenden. Jede Suchanfrage sollte ausschließlich Dokumente finden können, die der angemeldete Benutzer lesen darf. Ist diese Filterung nicht zuverlässig umsetzbar, sind getrennte Indizes nach Abteilung oder Schutzklasse die sicherere Architektur.
Vektoren sind ebenfalls keine harmlose Anonymisierung. Sie repräsentieren Inhalte mathematisch und gehören in dasselbe Schutzkonzept wie der zugrunde liegende Text. Verschlüsselung, Löschverfahren, Mandantentrennung und Sicherungen müssen deshalb auch den Vektorspeicher einschließen.
Typische Beobachtungen und ihre Bedeutung
- Das Produkt wirbt mit keinem Training durch Kundendaten: Prüfe zusätzlich Speicherung, menschliche Einsicht, Missbrauchsüberwachung und Löschfristen. Die Trainingsaussage deckt diese Bereiche nicht ab.
- Die KI läuft auf einem Windows-PC ohne Internet: Das senkt das Übertragungsrisiko, ersetzt aber weder Laufwerksverschlüsselung noch Benutzertrennung, Updates und lokale Protokollkontrolle.
- Ein privater Cloud-Endpunkt ist eingerichtet: Kontrolliere DNS-Auflösung, öffentliche Netzwerkfreigaben und die Identität der aufrufenden Anwendung. Ein vorhandener privater Endpunkt beweist nicht, dass der öffentliche Weg deaktiviert ist.
- Antworten enthalten Dokumente einer anderen Abteilung: Stoppe den Pilotbetrieb und prüfe Quellberechtigungen sowie Filter im Suchindex. Prompt-Regeln sind keine belastbare Zugriffssperre.
- Beschäftigte kopieren Daten in beliebige KI-Webseiten: Eine freigegebene Unternehmenslösung allein beendet diese Schattennutzung nicht. Browserzugriffe, Richtlinien, Schulung und ein praktikabler genehmigter Arbeitsweg müssen zusammenpassen.
Abnahmekriterien für vertrauliche Firmendaten
Eine private KI sollte erst dann produktiv auf sensible Quellen zugreifen, wenn die folgenden Punkte belegbar beantwortet sind:
- Der Betreiber kennt alle Orte, an denen Eingaben, Antworten, Dateien, Indizes und Protokolle gespeichert werden.
- Benutzer melden sich über zentral verwaltete Identitäten an; gemeinsam genutzte Konten und dauerhaft hinterlegte Schlüssel werden vermieden.
- Die Anwendung übernimmt Quellberechtigungen oder trennt Datenbestände technisch nach Schutzbedarf.
- Ausgehende Netzwerkverbindungen und Erweiterungen sind auf genehmigte Ziele begrenzt.
- Administratoren können Modellversionen, Datenquellen und Konfigurationsänderungen nachvollziehen.
- Aufbewahrung und Löschung wurden mit Testdaten praktisch überprüft.
- Ein Vorfallverfahren regelt die Sperrung von Konten, den Austausch von Schlüsseln und die Auswertung relevanter Protokolle.
- Die Fachabteilung hat geprüft, bei welchen Aufgaben falsche Antworten nur lästig und bei welchen sie geschäftskritisch wären.
Für einen kleinen, abgeschotteten Pilotversuch unter Windows sind Ollama oder llama.cpp oft der direkteste Einstieg. Ein zentraler interner Dienst lässt sich mit Open WebUI, LocalAI, vLLM oder einer containerisierten Plattform aufbauen, verlangt aber eigenes Betriebswissen. Azure AI Foundry beziehungsweise Azure OpenAI und Microsoft 365 Copilot verschieben einen Teil dieses Aufwands zum Plattformanbieter, machen die Prüfung von Mandant, Vertrag, Region, Berechtigungen und Protokollen jedoch nicht überflüssig. Die tragfähige Auswahl ist die Lösung, deren gesamte Datenkette das Unternehmen prüfen, begrenzen und wieder löschen kann.
