Ilustración editorial para IA local y privacidad: cómo comprobar qué datos salen de tu equipo
Imagen generada con gpt-image-2.5-sunburst para InferamaQuelle ↗
01

Was „lokal“ tatsächlich bedeutet

„Lokal“ kann unterschiedliche Dinge beschreiben: wo die Modellgewichte gespeichert sind, wo eine Antwort berechnet wird oder welche Teile des Arbeitsablaufs auf dem eigenen Rechner stattfinden. Diese Bedingungen sind nicht gleichbedeutend. Ein Modell kann heruntergeladen worden sein und auf dem Computer laufen, während die Anwendung für eine optionale Funktion einen externen Dienst abfragt, nach Updates sucht oder verfügbare Modelle recherchiert. Ebenso kann eine Anwendung eine Anfrage an einen Inferenzserver senden, der auf demselben Rechner läuft, während Gespräche oder Protokolle in Dateien gespeichert werden, auf die andere Nutzerinnen und Nutzer des Systems zugreifen können.

Die hilfreiche Frage lautet deshalb nicht nur: „Ist das Modell lokal?“, sondern: „Welche Komponenten sind an dieser Aufgabe beteiligt, welche Daten erhält jede davon, und welche Belege habe ich für ihr Verhalten?“ Zu prüfen ist die gesamte Grenze: Chat-Oberfläche, Prozess zum Laden des Modells, aktivierte Werkzeuge, Erweiterungen, Netzwerkverbindungen, Speicherorte und Backups. Die Bewertung gilt für eine konkrete Konfiguration: Anwendungsversion, Einstellungen, Betriebssystem, installiertes Modell und ausgeführte Aktionen.

Die Inferenz auf dem Gerät kann dazu beitragen, dass der Prompt für genau diesen Vorgang nicht an einen externen Anbieter gesendet werden muss. Sie beweist aber nicht, dass die gesamte Anwendung offline arbeitet. Ebenso schützt sie Informationen nicht automatisch vor anderen Konten mit Zugriff auf den Rechner, Schadsoftware, weitreichenden Berechtigungen oder Dateien, die nach dem Schließen der Anwendung erhalten bleiben. Entscheidend ist der Unterschied zwischen dem Ort der Berechnung, dem Weg der Daten und der Sicherheit des Geräts.

Drei Fragen, die nicht verwechselt werden sollten

FrageWas damit geklärt werden sollWas dadurch allein nicht bewiesen ist
Wo befinden sich die Modellgewichte?Ob sich die Modelldatei auf dem Gerät oder in einem entfernten Speicher befindet.Dass alle Anfragen, Funktionen oder Protokolle lokal bleiben.
Wo wird die Antwort berechnet?Ob die Inferenz für diese Anfrage auf dem Gerät oder bei einem entfernten Dienst stattfindet.Dass es keine weiteren Verbindungen oder zusätzliche Verarbeitung gibt.
Wohin gelangen die Daten des gesamten Arbeitsablaufs?Welche Komponenten Prompts, Dokumente, Ergebnisse und Metadaten erhalten.Dass das Gerät vor anderen Nutzern oder Prozessen geschützt ist.
02

Zeichnen Sie den Datenfluss auf, bevor Sie testen

Erstellen Sie ein Inventar aller beteiligten Komponenten, nicht nur des Modells. Berücksichtigen Sie die Anwendung mit der Chat-Oberfläche, den Inferenzserver, das Modell und dessen Download-Verwaltung. Ergänzen Sie anschließend Websuche, Werkzeuge, Erweiterungen, Add-ons, Update-Prüfungen und Optionen, die Cloud-Dienste verwenden könnten. Wenn sich in einer Anwendung zwischen lokalem und entferntem Betrieb umschalten lässt, halten Sie für jeden Test fest, welcher Modus aktiv ist. Die Beschriftung auf einer Oberfläche ersetzt nicht die Prüfung der tatsächlich verwendeten Einstellungen.

Notieren Sie für jede Komponente, welche Informationen sie erhalten könnte. Ein Prompt kann vertraulichen Text enthalten; ein angehängtes Dokument kann von einem Werkzeug gelesen werden; eine Suche kann die Suchanfrage übertragen; ein Protokoll kann Ein- und Ausgaben speichern. Gehen Sie nicht davon aus, dass all diese Daten gleich behandelt werden. Ein Dienst, der eine Antwort berechnet, eine Funktion, die das Internet abfragt, und eine Verlaufsdatei sind unterschiedliche Ziele und unterschiedliche Bereiche, in denen Daten offengelegt werden können.

Das Inventar sollte auch die einzelnen Aktivitäten auseinanderhalten. Ein Modell herunterzuladen, eine Erweiterung zu installieren, einen Prompt einzugeben, eine Datei anzuhängen, eine Suche aufzurufen und nach Updates zu suchen sind getrennte Aktionen. Werden sie gleichzeitig ausgeführt, lässt sich eine Änderung des Netzwerkverkehrs nur schwer zuordnen. Die NIST-Methodik zur Charakterisierung von Netzwerkverhalten bietet eine Grundlage dafür, Beobachtungen anhand vorab festgelegter Aktivitäten zu organisieren. Der Bericht bezieht sich auf IoT-Geräte und wird hier als Testmethode angepasst, nicht als Zertifizierung von KI-Anwendungen.

Erstes Inventar

  1. 01Notieren Sie Betriebssystem, Anwendungsversion, Konfiguration, Modell und aktivierte Funktionen.
  2. 02Listen Sie Prozesse, Dienste, Erweiterungen und Werkzeuge auf, die zum Arbeitsablauf gehören.
  3. 03Ordnen Sie jeder Aktion mögliche Eingaben zu: Prompt, Datei, Suchanfrage, Ergebnis oder Metadaten.
  4. 04Trennen Sie vorbereitende Aktionen wie Downloads und Installationen von der normalen Nutzung.
  5. 05Halten Sie fest, was Sie erwarten und welche konkrete Beobachtung diese Erwartung bestätigen oder widerlegen könnte.
03

Ein kontrollierter Test ohne Internetverbindung

Ein Test ohne Internetzugang zeigt, welche Funktionen nach der Vorbereitung der Umgebung weiter verfügbar sind. Er beweist jedoch nicht, dass zuvor niemals Daten übertragen wurden. Installieren Sie die Anwendung, laden Sie das zu prüfende Modell herunter und bereiten Sie die Testdokumente vor, bevor Sie die Verbindung trennen. Halten Sie fest, welche Ressourcen während dieser Vorbereitungsphase abgerufen wurden. Falls das Produkt Suche, bedarfsgesteuerte Downloads oder entfernte Werkzeuge anbietet, führen Sie diese als eigene Funktionen neben dem grundlegenden Chat auf.

Trennen Sie den Rechner mit einer überprüfbaren Methode vom Internet und dokumentieren Sie den Verbindungsstatus. Testen Sie einzeln einen einfachen Chat mit bereits geladenem Modell, eine Anfrage mit einem lokalen Dokument und jede optionale Funktion, die Sie untersuchen möchten. Notieren Sie, ob die Aufgabe abgeschlossen wird, mit einer Meldung fehlschlägt, wartet oder nur ein Teilergebnis liefert. Wiederholen Sie jeden Test unter vergleichbaren Bedingungen und ändern Sie nicht mehrere Optionen zwischen den Durchläufen.

Formulieren Sie das Ergebnis mit klaren Grenzen. Wenn ein Gespräch offline funktioniert, können Sie festhalten, dass genau diese Aufgabe in genau dieser Konfiguration während des Tests funktioniert hat. Daraus folgt nicht, dass die Anwendung niemals Daten überträgt, beim erneuten Verbinden keine Verbindungen aufbaut oder sich in einem anderen Modus gleich verhält. Wenn eine Funktion scheitert, zeigt das, dass der geprüfte Vorgang unter diesen Bedingungen ohne Netzwerk nicht verfügbar war. Es zeigt für sich genommen weder, welche Daten übertragen worden wären, noch an welches Ziel.

Die Dokumentation von LM Studio unterscheidet beispielsweise zwischen Aufgaben, die laut Anbieter offline verfügbar sind, etwa Chat und Arbeit mit Dokumenten, und Aktionen, die Netzwerkanfragen auslösen, etwa die Suche nach oder den Download von Modellen und die Prüfung auf Updates. Das veranschaulicht, wie eine Anwendung ihre Betriebsarten beschreiben kann. Es ersetzt jedoch nicht die Prüfung des konkreten Rechners, der Version und der Einstellungen.

04

Beobachten Sie den Netzwerkverkehr für jede Aktivität

Am aussagekräftigsten ist ein Test, bei dem Ereignisse voneinander getrennt und Notizen vor, während und nach jeder Aktion angefertigt werden. Erfassen Sie Verbindungen im Leerlauf. Starten Sie anschließend das Programm, laden Sie das Modell, senden Sie einen Test-Prompt, hängen Sie ein unbedenkliches Dokument an, aktivieren Sie eine Suche, installieren Sie eine Erweiterung und suchen Sie nach Updates. Wenn Sie Verbindungen eindeutig zuordnen möchten, bündeln Sie nicht alle Schritte in einer einzigen Sitzung. Wiederholen Sie wichtige Aktionen, um festzustellen, ob das beobachtete Muster erneut auftritt.

Dokumentieren Sie Zeitpunkt, Aktion, den zugehörigen Prozess, sofern er sich identifizieren lässt, das sichtbare Ziel und die ungefähre Dauer. Halten Sie auch die genaue Konfiguration und etwaige Fehlermeldungen fest. Die Beobachtung einer Verbindung reicht nicht aus, um zu behaupten, welche Inhalte übertragen wurden. Auch der Name eines Ziels belegt für sich genommen nicht, wie die Daten verarbeitet wurden. Wenn sich der Inhalt nicht überprüfen lässt, vermerken Sie diese Einschränkung, statt die Lücke mit einer Vermutung zu füllen.

Vergleichen Sie drei Situationen: Die Anwendung ist inaktiv, wird für einfache Aufgaben genutzt und führt jeweils eine optionale Funktion aus. Taucht während eines Updates oder Downloads eine Verbindung auf, trennen Sie diese Beobachtung vom Test des Prompts. Wenn Sie während eines Tests keinen Netzwerkverkehr beobachten, beschränken Sie Ihre Schlussfolgerung auf genau diesen Test und die eingesetzten Beobachtungswerkzeuge. Eine einzelne Aufzeichnung kann zeitweise, verzögert oder von einer anderen Komponente gestartete Verbindungen übersehen. Bei einer Prüfung mit größeren Auswirkungen sollte eine technische Fachperson die Methode dokumentieren und das Verfahren wiederholen.

Mindestangaben für ein Beobachtungsprotokoll

FeldWas zu notieren istWarum es wichtig ist
AktivitätDie genaue Aktion, etwa das Laden des Modells oder das Senden des Test-Prompts.Hilft, eine Beobachtung einem Ereignis zuzuordnen.
ZeitpunktStart- und Endzeit sowie die Angabe, ob die Anwendung inaktiv war.Ermöglicht die Unterscheidung zwischen Hintergrundverbindungen und angeforderter Aktivität.
BeobachtungProzess, sichtbares Ziel, Dauer und verwendetes Erfassungswerkzeug.Macht die Prüfung nachvollziehbar, ohne nicht beobachtete Inhalte zu unterstellen.
EinschränkungWas nicht festgestellt werden konnte, etwa der übertragene Inhalt oder der Ursprung des Prozesses.Verhindert, dass eine Vermutung als überprüfte Tatsache dargestellt wird.
05

Verläufe, Protokolle und Berechtigungen prüfen

Der Datenschutz endet nicht mit der Erstellung einer Antwort. Prüfen Sie, wo Gespräche, temporäre Dokumente, Cache-Dateien und Protokolle gespeichert werden. Kontrollieren Sie sowohl die Anwendungseinstellungen als auch die erzeugten Dateien und stellen Sie fest, welche Systemkonten sie lesen können. Beziehen Sie auch synchronisierte Ordner, Backups und Diagnosewerkzeuge ein, sofern sie auf dem Rechner verwendet werden. Nehmen Sie weder an, dass das Schließen eines Fensters die Daten löscht, noch, dass eine Bereinigungsoption alle Komponenten erfasst.

Als konkretes Beispiel gibt die Dokumentation von LM Studio an, dass Gespräche in JSON-Dateien gespeichert werden, und nennt Speicherorte für verschiedene Betriebssysteme. In der Dokumentation zum Befehl für den Protokoll-Stream wird darauf hingewiesen, dass die Protokolle Ein- und Ausgabetext von Modell und Server enthalten können. Diese Angaben sind für die Prüfung dieser Anwendung und ihrer Konfiguration relevant und sollten nicht ohne Weiteres auf andere Laufzeitumgebungen übertragen werden.

Testen Sie vor der Eingabe sensibler Informationen die Löschfunktion mit erfundenen Daten: Suchen Sie die Dateien vor und nach dem Test, verwenden Sie den dokumentierten Löschmechanismus und kontrollieren Sie, was zurückbleibt. Erklärt das Produkt weder, wo Daten gespeichert werden, noch, wie sie gelöscht werden, halten Sie dies als offene Frage fest und bitten Sie den Anbieter oder die zuständige Systemverwaltung um Klärung. Die Berechtigungen des Anwendungskontos einzuschränken kann den Zugriff auf Dateien begrenzen. Das ersetzt jedoch weder Systemschutz noch gegebenenfalls Verschlüsselung oder eine Aufbewahrungsrichtlinie.

06

Ein Server auf dem Rechner kann im Netzwerk erreichbar sein

Eine lokale API ermöglicht es einer Client-Anwendung, Anfragen an den Inferenzserver zu senden. „Lokal“ kann bedeuten, dass der Prozess auf dem eigenen Rechner läuft. Von wo aus der Server erreichbar ist, hängt jedoch davon ab, an welcher Netzwerkschnittstelle er lauscht. Ein Dienst, der an eine Loopback-Schnittstelle gebunden ist, ist für Anfragen vom selben Gerät vorgesehen. Ein Dienst, der über eine Netzwerkschnittstelle erreichbar ist, kann je nach Konfiguration und Netzwerkregeln auch Verbindungen von anderen Geräten annehmen. Prüfen Sie das tatsächliche Verhalten, statt es allein aus der Bezeichnung „lokal“ abzuleiten.

Kontrollieren Sie die Listening-Adresse, den Port, die Optionen für den Netzwerkzugriff und die Authentifizierung. Stellen Sie fest, ob ein anderes Gerät im Netzwerk den Dienst erreichen und ohne Zugangsdaten Anfragen senden kann. Tun Sie dies nur in einer autorisierten Umgebung und mit einem Testmodell sowie Testinhalten. Eine Antwort des Servers beweist nicht, dass alle Werkzeuge abgeschirmt sind. Prüfen Sie gesondert, auf welche Dateien, Funktionen oder Erweiterungen der anfragende Client zugreifen kann.

Die Dokumentation von LM Studio beschreibt einen lokalen API-Server, der über localhost oder im Netzwerk verwendet werden kann. Das ist ein Grund, die aktive Schnittstelle und die tatsächlichen Einstellungen zu prüfen. Es beweist nicht, dass jede Installation im Netzwerk lauscht oder standardmäßig offengelegt ist. Wenn Sie keinen Zugriff von anderen Geräten benötigen, beschränken Sie den Dienst mithilfe der verfügbaren Optionen und Systemregeln auf den eigenen Rechner. Ist ein Netzwerkzugriff erforderlich, setzen Sie Zugriffskontrollen ein und beschränken Sie die Berechtigungen des Prozesses auf das Notwendige.

Prüfung der Erreichbarkeit des Servers

  1. 01Stellen Sie fest, welcher Prozess die API bereitstellt und an welcher Schnittstelle und welchem Port er lauscht.
  2. 02Prüfen Sie, ob der Dienst nur Anfragen vom eigenen Rechner oder auch aus dem Netzwerk annimmt.
  3. 03Versuchen Sie mit entsprechender Berechtigung, von einem anderen Gerät eine unbedenkliche Anfrage zu senden.
  4. 04Prüfen Sie, ob eine Authentifizierung erforderlich ist und welche Aktionen die API erlaubt.
  5. 05Deaktivieren Sie nicht benötigte Zugriffe und wiederholen Sie den Test nach einer Änderung der Konfiguration.
07

Beobachtungen, Anbieterangaben und offene Fragen trennen

Ein nützlicher Bericht unterscheidet drei Ebenen. Erstens die Beobachtungen: etwa, dass eine bestimmte Funktion offline fehlschlug oder während einer konkreten Aktion eine Verbindung erfasst wurde. Zweitens die Angaben des Anbieters in Dokumentation oder Datenschutzrichtlinien, zum Beispiel welche Funktionen laut Anbieter offline arbeiten oder in welchen Fällen Daten übertragen werden. Drittens das, was noch nicht geklärt ist: der Inhalt einer verschlüsselten Verbindung, die nicht näher untersucht wurde, das Verhalten einer anderen Version oder der Zugriff fremder Prozesse auf Dateien.

Eine Datenschutzrichtlinie ist eine Primärquelle für die Aussagen des Anbieters zu seinem Produkt, überprüft aber nicht unabhängig, was eine konkrete Installation tatsächlich getan hat. Umgekehrt beschreibt eine Netzwerkaufzeichnung, was ein Werkzeug in einem bestimmten Zeitraum und unter einer bestimmten Konfiguration beobachtet hat. Sie ersetzt keine vertragliche Erklärung zur Aufbewahrung oder Verarbeitung. Nutzen Sie beide Arten von Belegen und halten Sie jeweils Datum, Version und Bedingungen fest.

Die folgende Matrix hilft dabei, keine weiterreichenden Schlussfolgerungen zu ziehen, als der Test erlaubt. Wenn ein Ergebnis von einer Option abhängt, dokumentieren Sie sowohl den beobachteten Zustand als auch den genauen Wert dieser Option. Lässt sich eine Beobachtung nicht wiederholen oder ihre Ursache nicht bestimmen, kennzeichnen Sie sie als offen. Bei Entscheidungen mit hohen Risiken ersetzt eine informelle Prüfung keine Überprüfung der Sicherheits- und Datenschutzanforderungen sowie der geltenden rechtlichen Vorgaben.

Matrix für die Ergebnisdarstellung

BelegVorsichtige SchlussfolgerungNicht belegte Schlussfolgerung
Die Aufgabe wurde bei getrennter Netzwerkverbindung abgeschlossen.Die Aufgabe funktionierte in der geprüften Konfiguration offline.Die Anwendung überträgt niemals Daten.
Während einer Suche wurde eine Verbindung beobachtet.Während dieser Aktivität trat zeitlich eine Verbindung auf.Der vollständige Prompt wurde an ein bestimmtes Ziel gesendet, sofern der Inhalt nicht beobachtet wurde.
Die Dokumentation erklärt, eine Funktion arbeite offline.Der Anbieter beschreibt die Funktion als offline verfügbar.Die geprüfte Installation verhielt sich ohne Test genau so.
In einer Sitzung wurde kein Netzwerkverkehr festgestellt.Das verwendete Werkzeug beobachtete während dieses Tests keinen Netzwerkverkehr.Es fand zu keinem Zeitpunkt eine Netzwerkkommunikation statt.
08

Checkliste vor der Nutzung sensibler Daten

Die abschließende Entscheidung sollte weder von einer Marketingbezeichnung noch von einem einzelnen Test abhängen. Berücksichtigen Sie die Art der Daten, die möglichen Folgen einer Offenlegung, die tatsächlich benötigten Funktionen, den physischen und logischen Zugriff auf den Rechner, die Qualität der gesammelten Belege sowie die Möglichkeit, Protokolle zu löschen oder zu kontrollieren. Lässt sich eine wichtige Frage nicht klären, behandeln Sie sie nicht als günstige Annahme: Beschränken Sie die Nutzung, deaktivieren Sie die fragliche Funktion oder setzen Sie die Prüfung aus, bis eine überprüfbare Antwort vorliegt.

Führen Sie ein kurzes Protokoll der Konfiguration und des Testverfahrens, damit die Ergebnisse nachvollziehbar bleiben. Wiederholen Sie die Tests nach wichtigen Updates, Änderungen an Erweiterungen oder Anpassungen der Netzwerkeinstellungen. Das Ergebnis beschreibt die geprüfte Konfiguration und nicht alle künftigen Zustände. Speichern Sie Screenshots oder Notizen ohne sensible Daten und beschränken Sie, wer sie einsehen kann. Wird eine unerwartete Übertragung festgestellt, setzen Sie die Verwendung echter Daten aus, sichern Sie nicht sensible Belege und lassen Sie die Umgebung vor der Wiederaufnahme technisch prüfen.

Nutzen Sie diese Liste als praktische Entscheidungshilfe, nicht als Datenschutz-Zertifizierung. Wenn Sie lokale Modelle erkunden, einen Vergleich heranziehen oder weitere Werkzeuge entdecken möchten, können Sie bei den Inferama-Leitfäden zu lokalen Modellen, den Vergleichen und dem Entdeckungsbereich beginnen. Die Datenschutzprüfung muss jedoch für die konkrete Anwendung und Konfiguration erfolgen, die tatsächlich eingesetzt werden sollen.

Mindestkontrollen zum Abschluss der Prüfung

  1. 01Legen Sie fest, welche Informationen sensibel sind, und testen Sie zuerst mit erfundenen Daten.
  2. 02Identifizieren Sie lokale, entfernte und optionale Funktionen und deaktivieren Sie nicht benötigte Funktionen.
  3. 03Wiederholen Sie Offline-Tests und beobachten Sie den Netzwerkverkehr getrennt nach Aktivitäten.
  4. 04Suchen Sie Verläufe, Protokolle und temporäre Dateien; prüfen Sie Berechtigungen und Löschmöglichkeiten.
  5. 05Prüfen Sie die Listening-Schnittstelle und den Zugriff anderer Geräte auf den Server.
  6. 06Dokumentieren Sie Beobachtungen, Anbieterangaben und noch offene Fragen getrennt voneinander.
  7. 07Verwenden Sie keine sensiblen Daten weiter, wenn unerwarteter Netzwerkverkehr auftritt oder sich eine relevante Offenlegung nicht begrenzen lässt.

Offene Fragen

  • Netzwerkverhalten, Speicherung und Berechtigungen hängen von der konkreten Anwendung, Version, dem Betriebssystem und der Konfiguration ab.
  • Die verfügbaren Quellen belegen nicht das Verhalten sämtlicher lokaler KI-Anwendungen oder aller Erweiterungen.
  • Ein einzelner Test erkennt möglicherweise keine sporadischen oder verzögerten Verbindungen und keine Kommunikation, die ein anderer Prozess initiiert.
  • Die Beobachtung von Netzwerkzielen zeigt nicht zwangsläufig den übertragenen Inhalt oder dessen anschließende Verarbeitung.
  • Datenschutzaussagen eines Anbieters sind keine unabhängige Überprüfung einer konkreten Installation.
  • Ob ein API-Server erreichbar ist, muss in der geprüften Umgebung festgestellt werden; es lässt sich nicht allein aus allgemeiner Dokumentation ableiten.
09

Weiter entdecken

09

Verwendete Quellen

03

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.

Korrektur vorschlagen