Lokale KI oder Cloud: Welche Architektur passt?

Zuerst den Datenweg zeichnen

Beginnen Sie bei den Informationen, die ein Nutzer oder Fachsystem einliefert. Wohin gelangen Dokumente, Suchanfragen und gefundene Textstellen? Welche Dienste erstellen Suchindizes oder numerische Textrepräsentationen? Wo landen Antworten, technische Protokolle und Sicherungskopien? Auch Identitätsdienste, Überwachung und angebundene Werkzeuge gehören in dieses Bild. Für jeden Übergang braucht es einen nachvollziehbaren Zweck und eine passende Zugriffsregel.

NISTs Zero-Trust-Architektur leitet Vertrauen nicht allein aus dem Netzwerkstandort ab. Das ist auch hier ein hilfreicher Grundsatz: Ein lokal erreichbarer Dienst braucht weiterhin Authentifizierung und Berechtigungen. „Lokal“ beschreibt einen Betriebsort. Datenschutz und die Erfüllung konkreter Vorgaben hängen zusätzlich von Konfiguration, Prozessen und tatsächlicher Nutzung ab.

Quellen: NIST · Zero Trust Architecture

Lokaler Betrieb braucht einen Eigentümer

Eigene Infrastruktur ist besonders prüfenswert, wenn ein Workflow ohne externe Modellverbindung arbeiten soll oder feste Grenzen für Datenübertragungen bestehen. Dazu gehört eine nüchterne Betriebsplanung: Wer aktualisiert das System, verwaltet Schlüssel und behandelt Ausfälle? Wer kontrolliert Speicherorte, Backups und Löschfristen? Diese Aufgaben bleiben bestehen, auch wenn die Modellsoftware leicht zu installieren ist.

Selbst die Bezeichnung einer lokalen Laufzeit reicht nicht als Nachweis. Ollama dokumentiert beispielsweise einen gesonderten Modus, der Cloud-Modelle und Websuche deaktiviert. Für eine konkrete Installation müssen solche Einstellungen und ergänzende Anwendungen zusammen geprüft werden. Testen Sie außerdem realistische Dokumentlängen und gleichzeitige Nutzer. Ein Modell, das in den Speicher passt, erfüllt damit noch keine vereinbarte Antwortzeit unter Last.

Quellen: Ollama · FAQ

Cloud-Eigenschaften konkret vereinbaren

Bei einem Cloud-Angebot zählen der konkrete Dienst, seine Konfiguration und die vereinbarten Bedingungen. Microsoft unterscheidet für Foundry etwa zwischen Verarbeitungsorten verschiedener Bereitstellungstypen und der Speicherung durch zustandsbehaftete Funktionen. Eine Aussage zum Modelltraining beantwortet deshalb nicht zugleich die Frage, welche Inhalte für den Betrieb gespeichert oder verarbeitet werden.

Für den eigenen Workflow sollten Datenverantwortliche und Betrieb gemeinsam klären, welche Funktionen genutzt werden dürfen, wer Zugriff erhält und wie Aufbewahrung sowie Löschung funktionieren. Prüfen Sie auch Fehlersuche und Support: Welche Inhalte würden dabei sichtbar? Halten Sie die tatsächlich gewählten Optionen fest. Produktnamen oder eine ausgewählte Region ersetzen diese Beschreibung nicht. Änderungen an Funktionen oder Einstellungen müssen später erneut beurteilt werden.

Quellen: Microsoft · Data, privacy, and security for Foundry Models

Hybrid an einer überprüfbaren Grenze aufbauen

Eine hybride Architektur kann Daten lokal vorverarbeiten und ausgewählte Aufgaben an einen externen Dienst geben. Die Grenze muss jedoch inhaltlich definiert sein. Wenn eine lokale Suche vertrauliche Passagen an ein Cloud-Modell übergibt, haben diese Passagen den lokalen Bereich verlassen. Auch eine Zusammenfassung kann sensible Informationen enthalten. Legen Sie deshalb fest, welche Daten übertragen werden dürfen und was bei unklarer Einstufung geschieht.

Vergleichen Sie die zulässigen Varianten anschließend anhand desselben Referenz-Workflows: fachliche Qualität, Antwortzeit, Ausfallverhalten, laufender Aufwand und Wechselmöglichkeiten. Ein kurzer Betriebsversuch sollte auch einen verlorenen Netzwerkzugang oder einen nicht erreichbaren Dienst umfassen. Die passende Architektur ist diejenige, deren Leistungsfähigkeit und Grenzen Ihr Team nachweisen und im Alltag tragen kann.