Lokale KI und die DSGVO, was sie wirklich löst und was nicht

"Wir machen das lokal, dann haben wir kein Datenschutzproblem." Diesen Satz hört man oft, und er ist zur Hälfte richtig. Die Hälfte, die stimmt, ist wichtig genug, dass sich lokale Modelle allein deswegen lohnen können. Die Hälfte, die nicht stimmt, holt Dich ein, wenn Du sie nicht kennst.

Dieses Playbook trennt beides. Es ist keine Rechtsberatung und ersetzt keine, es sortiert die Fragen, damit Du weißt, welche Du überhaupt stellen musst.

1. Versteh, was lokal tatsächlich beseitigt

Das eigentliche Problem bei Cloud-Diensten ist die Übermittlung. Sobald ein personenbezogenes Datum an einen Anbieter geht, brauchst Du eine Rechtsgrundlage dafür, eine geklärte Rollenverteilung mit dem passenden Vertrag, und bei Anbietern außerhalb der EU eine Antwort auf die Frage, wie der Transfer abgesichert ist. Die Rollenfrage wird dabei am häufigsten falsch beantwortet: ein Auftragsverarbeitungsvertrag passt nur, wenn der Anbieter wirklich Auftragsverarbeiter ist. Nutzt er die Daten für eigene Zwecke, ist er eigener oder gemeinsamer Verantwortlicher, und dann braucht es etwas anderes. Das entscheidet sich pro Dienst und pro Zweck, nicht pauschal.

Läuft das Modell auf Deiner Maschine, entfällt diese Kette für den Inferenz-Schritt. Dafür gibt es keinen Empfänger, weil nichts empfangen wird.

Entscheidend ist aber die ganze Kette, nicht nur das Modell. Eine lokale Oberfläche kann trotzdem nach draußen funken: eingeschaltete Websuche, ein Embedding-Dienst in der Cloud für die Dokumentensuche, ein angebundenes Fremdmodell als Zweitmeinung, Telemetrie, ein Cloud-Backup des Verlaufs. In all diesen Fällen laufen Deine Daten doch hinaus, obwohl das Modell lokal rechnet. Bevor sensible Dokumente hineingehen, prüf deshalb einmal aktiv: Websuche aus, Embeddings lokal, kein Fremdmodell eingetragen, Telemetrie aus, Port nur auf localhost gebunden, und das Backup-Ziel liegt nachweislich im eigenen Haus statt in einer Cloud. Erst wenn das steht, stimmt der Satz "nichts verlässt das Haus".

Tipp: Genau hier liegt der Wert für Kanzleien, Praxen, Steuerberatung und Personalabteilungen. Nicht weil das Modell besser wäre, sondern weil die Frage nach der Übermittlung bei sauber abgedichtetem Aufbau gar nicht erst aufkommt.

2. Versteh, was lokal nicht beseitigt

Alles andere gilt weiter. Du bist Verantwortlicher im Sinne der Verordnung, mit allem was dazugehört.

Du brauchst weiterhin eine Rechtsgrundlage für die Verarbeitung selbst. Ein Eintrag im Verzeichnis der Verarbeitungstätigkeiten ist fällig. Betroffenenrechte gelten unverändert, also Auskunft, Berichtigung, Löschung. Der Grundsatz der Datenminimierung gilt. Und wenn die Verarbeitung ein hohes Risiko birgt, brauchst Du eine Datenschutz-Folgenabschätzung, ganz gleich wo die Rechenarbeit passiert.

Tipp: Der häufigste Denkfehler ist, dass "auf meinem Rechner" gleich "privat" bedeutet. Ein Firmenlaptop mit Kundendaten ist eine Verarbeitung, auch offline.

3. Klär, ob überhaupt personenbezogene Daten im Spiel sind

Bevor Du in die schweren Fragen einsteigst, prüf die einfache. Viele Anwendungsfälle brauchen gar keine Personendaten. Eine Produktbeschreibung umschreiben, ein technisches Handbuch zusammenfassen, Code kommentieren, all das ist unkritisch.

Wenn Du personenbezogene Daten weglassen kannst, lass sie weg. Das ist die billigste Lösung überhaupt und sie kostet nichts außer einem Moment Nachdenken.

Tipp: Pseudonymisieren hilft, aber es macht Daten nicht anonym. Wenn ein Name durch eine Kennung ersetzt wird und Du die Zuordnungstabelle behältst, ist es weiterhin personenbezogen.

4. Schau nach, wo das Modell selbst herkommt

Das Modell ist eine Datei mit Gewichten. Sie enthält keine Kundendaten, aber sie kommt von jemandem, und die Lizenz regelt was Du damit darfst.

Apache 2.0 und MIT sind unkompliziert. Andere Lizenzen haben Einschränkungen, etwa zur Nutzerzahl oder zu bestimmten Einsatzgebieten. Für den betrieblichen Einsatz gehört das geprüft, nicht angenommen.

Tipp: Lad Modelle von der offiziellen Quelle der jeweiligen Familie oder aus der offiziellen Bibliothek Deiner Laufzeitumgebung. Eine anonym hochgeladene Kopie mit Zusatzversprechen im Namen ist ein unnötiges Risiko.

5. Sichere den Rechner, auf dem es läuft

Wenn die Cloud wegfällt, wanderst Du in die Verantwortung. Der Rechner mit dem lokalen Modell und den verarbeiteten Dokumenten ist jetzt der Ort, an dem die Daten liegen.

Festplattenverschlüsselung, Bildschirmsperre, Zugriffsbeschränkung, ein Backup-Konzept. Das sind technische und organisatorische Maßnahmen, und sie sind bei lokaler Verarbeitung nicht weniger nötig als vorher, sondern mehr.

Tipp: Prüf, wohin Deine Oberfläche den Gesprächsverlauf schreibt. Manche legen ihn unverschlüsselt in ein Verzeichnis im Benutzerordner. Das ist eine Sammlung Deiner sensibelsten Eingaben an einer Stelle, an die niemand denkt.

6. Mach den Port nicht versehentlich auf

Lokale Laufzeitumgebungen lauschen standardmäßig nur auf dem eigenen Rechner. Das ist die richtige Voreinstellung. In Anleitungen steht trotzdem oft, man solle die Bindung auf alle Schnittstellen ändern, damit man vom Handy aus zugreifen kann.

Damit ist das Modell für jeden im selben Netz erreichbar, in der Regel ohne Anmeldung. In einem Büronetz oder gar mit einer Portfreigabe im Router ist das offen.

Tipp: Wenn Du wirklich von woanders zugreifen musst, nimm einen verschlüsselten Tunnel statt einer Freigabe. Die Bequemlichkeit einer offenen Adresse ist es nicht wert.

7. Denk an die Protokolle

Lokal heißt nicht spurenlos. Laufzeitumgebungen schreiben Protokolle, Oberflächen speichern Verläufe, manche Werkzeuge legen Zwischenstände in einer Datenbank ab.

Wenn dort personenbezogene Daten landen, sind das Verarbeitungen mit Speicherdauer. Also gehört festgelegt, wie lange sie bleiben und wer sie löschen kann. Auf ein Auskunftsersuchen antworten zu müssen und dann festzustellen, dass niemand weiß wo überall etwas liegt, ist eine unangenehme halbe Stunde.

Tipp: Schreib einmal auf, welche drei bis fünf Orte Daten aufnehmen. Diese Liste ist die halbe Miete für das Verarbeitungsverzeichnis.

8. Sortier den EU AI Act getrennt von der DSGVO

Das sind zwei verschiedene Regelwerke, und sie werden regelmäßig vermischt. Die DSGVO fragt, was mit personenbezogenen Daten passiert. Der AI Act fragt, was das System tut und welches Risiko davon ausgeht.

Die Fristen sind gestaffelt, und wichtiger noch: Artikel 50 verteilt die Pflichten auf zwei verschiedene Rollen. Das wird ständig verwechselt.

Als Anbieter eines KI-Systems trifft Dich Absatz 1, die Offenlegung, dass ein Mensch mit einem KI-System spricht, und Absatz 2, die maschinenlesbare Kennzeichnung erzeugter Inhalte. Als Betreiber, der ein fremdes System einsetzt, trifft Dich Absatz 4: Deepfakes offenlegen und KI-Texte kenntlich machen, die zu Themen öffentlichen Interesses veröffentlicht werden. Absatz 4 kennt Ausnahmen, aber sie sind enger als ihr Ruf: bei künstlerischen Werken entfällt die Offenlegung nicht, sie wird nur zurückhaltender ausgestaltet, und die Ausnahme für Texte greift erst, wenn ein Mensch den Inhalt geprüft hat und jemand die redaktionelle Verantwortung trägt. Auf die Anbieterpflichten aus Absatz 1 und 2 wirken diese Ausnahmen nicht. Wenn Du Dich auf eine davon stützen willst, lies den Wortlaut, nicht diese Zusammenfassung.

Zeitlich gilt für diese Transparenz-Pflichten der 2. August 2026. Für generative Systeme, die vor diesem Datum in Verkehr gebracht wurden, läuft die Frist für die maschinenlesbare Kennzeichnung nach Absatz 2 bis zum 2. Dezember 2026. Die Hochrisiko-Pflichten wurden durch das Digital Omnibus vom 8. Juli 2026 um mehr als ein Jahr verschoben; Artikel 50 blieb unberührt. Ein konkretes Hochrisiko-Datum nenn bitte nur nach einem Blick ins Amtsblatt, die Verschiebung ist frisch und die Sekundärquellen widersprechen sich.

Für den Alltag heißt das: prüf zuerst, in welcher Rolle Du bist. Wer ein lokales Modell nur für sich selbst laufen lässt und nichts veröffentlicht, ist von Absatz 4 gar nicht betroffen.

Dass Du ein Modell selbst betreibst, ändert an dieser Einordnung nichts. Was zählt, ist der Zweck.

Tipp: Die Details und die Abgrenzung stehen ausführlich in DACH-Legal, EU AI Act und DSGVO. Dieses Playbook nennt sie nur so weit, wie sie für lokale Aufbauten zählen.

9. Erklär den Vorteil richtig, nicht zu groß

Wenn Du intern oder beim Kunden für lokale Verarbeitung wirbst, formulier es genau. "Die Daten verlassen unser Haus nicht" ist richtig und stark. "Wir sind damit DSGVO-konform" ist falsch, weil Konformität von der ganzen Verarbeitung abhängt und nicht vom Ort der Rechenarbeit.

Der zweite Satz fällt Dir bei der ersten kritischen Nachfrage auf die Füße. Der erste hält.

Tipp: Wer eine Rechtsaussage in ein Angebot schreibt, sollte sie vorher von jemandem prüfen lassen, der dafür haftet. Das ist der Datenschutzbeauftragte oder ein Anwalt, nicht die KI und nicht dieses Playbook.

10. Schreib den Aufbau auf, bevor jemand fragt

Eine Seite reicht. Welches Modell, auf welcher Maschine, wer hat Zugriff, welche Daten gehen hinein, wo wird was gespeichert, wie lange, wer darf löschen.

Diese eine Seite ist der Unterschied zwischen einem Aufbau, der eine Prüfung übersteht, und einem, bei dem alle anfangen zu rekonstruieren. Sie zu schreiben dauert eine halbe Stunde, wenn Du die Schritte oben durchgegangen bist.

Tipp: Wenn im Team mehrere mit KI arbeiten, gehört dazu eine kurze Regel, was hinein darf und was nicht. Eine Vorlage dafür steht in Die KI-Richtlinie für kleine Teams.

Was als nächstes

Wenn Du den technischen Aufbau noch nicht stehen hast, fang mit Dein erstes lokales KI-Modell in 30 Minuten an. Die Frage nach der passenden Größe klärt Welches lokale Modell zu Deiner Hardware passt. Und für den Alltag mit Cloud-Werkzeugen, wo die Übermittlung eben doch stattfindet, gibt es Datenschutz beim Arbeiten mit KI-Tools.

Source

Dieses Playbook ist Orientierung, keine Rechtsberatung. Fristen und Auslegungen ändern sich, prüf sie an der Primärquelle.

• Verordnung (EU) 2024/1689 im Amtsblatt, amtliche Fassung (Artikel 50 und alles Übrige): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• EU-Kommission, Durchsetzung des AI Act: https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
• Lesbare Aufbereitung von Artikel 50 (keine amtliche Quelle, zum Einstieg): https://artificialintelligenceact.eu/article/50/
• Die Verschiebung der Hochrisiko-Fristen stammt aus dem Digital-Omnibus-Paket vom Sommer 2026. Den Änderungsrechtsakt selbst suchst Du bei Bedarf über EUR-Lex, ich verlinke hier bewusst keine Sekundärquelle dafür.
• Datenschutzkonferenz, Orientierungshilfe zu KI und Datenschutz: https://www.datenschutzkonferenz-online.de