Dafür haben wir einen Schlüsseltresor mit einem Sprachmodell verbunden, das vollständig lokal auf einem Arbeitsplatzrechner läuft. Die Idee dahinter: Das Modell soll natürliche Sprache verstehen und daraus konkrete Aktionen ableiten können – etwa einen bestimmten Eintrag finden oder Werte aus einer Konfigurationsdatei übernehmen.
Dabei ging es nicht darum, einen möglichst leistungsfähigen KI-Assistenten zu bauen. Wir wollten herausfinden, wie weit ein vergleichsweise kleines lokales Modell im praktischen Einsatz kommt – und welche Aufgaben besser durch klassische Softwarelogik abgesichert werden sollten.
Das Ergebnis ist interessant: Für klar abgegrenzte Aufgaben sind lokale Modelle bereits erstaunlich leistungsfähig. Gleichzeitig zeigen sich sehr deutlich ihre Grenzen.
Warum überhaupt ein lokales Sprachmodell?
In modernen Softwareprojekten entstehen schnell viele Zugangsdaten: Datenbank-Schlüssel, API-Keys, Tokens für externe Dienste, Webhook-Secrets oder Zugangsdaten für Deployment und E-Mail-Versand.
Diese Informationen müssen sicher gespeichert und verwaltet werden. Gleichzeitig möchte man sie im Alltag schnell wiederfinden können.
Ein klassischer Passwort- oder Schlüsseltresor löst das Speichern und Suchen. Ein Sprachmodell eröffnet darüber hinaus eine natürliche Möglichkeit, mit diesen Informationen zu arbeiten.
Statt sich durch Listen zu klicken, könnte man beispielsweise fragen:
„Welcher Key gehört zu Supabase?“
Oder:
„Übernimm aus dieser Konfigurationsdatei nur die Datenbank-URL und den Stripe-Key.“
Bei einem Cloud-basierten KI-Assistenten müssten dafür allerdings sensible Informationen an einen externen Dienst übermittelt werden.
Ein lokales Sprachmodell verfolgt einen anderen Ansatz: Die Verarbeitung findet direkt auf dem eigenen Rechner statt.
Das bedeutet: Die sensiblen Daten müssen den Rechner nicht verlassen, um vom Modell verarbeitet zu werden.
Die Hardware: ein normaler Arbeitsplatzrechner
Für den Versuch war keine spezielle KI-Workstation notwendig. Zum Einsatz kam ein handelsüblicher Windows-Rechner:
- Grafikkarte: NVIDIA GeForce RTX 5060 Ti, 16 GB VRAM
- Betriebssystem: Windows 11 Pro
- Laufzeitumgebung: Ollama, Node.js
Die wichtigste Zahl ist dabei der VRAM.
VRAM ist vereinfacht gesagt der Arbeitsspeicher der Grafikkarte. Ein Sprachmodell benötigt diesen Speicher, um seine Berechnungen schnell durchführen zu können.
Je größer das Modell, desto mehr Speicher wird benötigt. Passt ein Modell nicht vollständig in den verfügbaren Grafikspeicher, müssen Teile der Berechnung auf den Prozessor ausgelagert werden. Das kann die Geschwindigkeit erheblich reduzieren.
Mit 16 GB VRAM bewegt man sich daher in einem Bereich, in dem bereits leistungsfähige lokale Modelle sinnvoll eingesetzt werden können.
Das Modell: Qwen3 14B
Für den Versuch haben wir Qwen3 14B verwendet, ein offenes Sprachmodell aus der Qwen-Modellfamilie.
Die wichtigsten Eckdaten:
- Parameter: 14,8 Milliarden
- Quantisierung: Q4_K_M
- Modellgröße: ca. 9,3 GB
- VRAM-Verbrauch: ca. 10 GB
- Kontextfenster: 8.192 Tokens
- Berechnung: vollständig auf der GPU
Was bedeutet „14 Milliarden Parameter“?
Parameter kann man sich vereinfacht als die vielen Stellschrauben vorstellen, die ein Sprachmodell während seines Trainings gelernt hat.
Mehr Parameter bedeuten grundsätzlich mehr Kapazität. Gleichzeitig steigt aber auch der Speicherbedarf.
Hier kommt die Quantisierung ins Spiel.
Ein Sprachmodell besteht aus Milliarden von Zahlen. Werden diese Zahlen mit hoher Genauigkeit gespeichert, benötigt das Modell sehr viel Speicher. Bei der Quantisierung werden sie kompakter dargestellt – in unserem Fall mit ungefähr 4 Bit.
Dadurch wird das Modell deutlich kleiner und kann auf einer normalen Grafikkarte betrieben werden. Der damit verbundene Qualitätsverlust ist für unsere Anwendung im Alltag kaum relevant.
Warum dieses Modell?
Bei der Auswahl waren vier Punkte entscheidend.
1. Es kann Werkzeuge verwenden
Unser Ziel war kein klassischer Chatbot, der lediglich Texte formuliert.
Das Modell sollte Aktionen auslösen können. Zum Beispiel:
- einen Eintrag suchen,
- einen Eintrag auswählen,
- Daten aus einer Datei übernehmen,
- bestimmte Werte in die Zwischenablage kopieren.
Diese Fähigkeit wird häufig als Tool-Calling bezeichnet.
Vereinfacht gesagt bekommt das Modell eine Liste von Werkzeugen und deren Funktionen. Wenn ein Nutzer eine Anfrage stellt, entscheidet das Modell, welches Werkzeug benötigt wird und mit welchen Parametern es aufgerufen werden soll.
Genau diese Übersetzung von natürlicher Sprache in strukturierte Aktionen ist für unseren Anwendungsfall entscheidend.
2. Das Modell passt in den verfügbaren Speicher
Das Modell benötigt rund 10 GB VRAM. Damit bleiben auf einer Grafikkarte mit 16 GB noch Reserven für weitere Berechnungen.
Das ist wichtig, weil nicht nur das Modell selbst Speicher benötigt. Auch der sogenannte Kontext – also der Inhalt des aktuellen Gesprächs und weitere Informationen, die das Modell berücksichtigen soll – benötigt Speicher.
Wir haben das mögliche Kontextfenster deshalb bewusst auf 8.192 Tokens begrenzt. Für kurze Fragen an einen Schlüsseltresor ist ein wesentlich größeres Kontextfenster nicht notwendig.
3. Es funktioniert gut mit deutscher Sprache
Das klingt zunächst nebensächlich, ist für die tägliche Nutzung aber wichtig.
Ein Werkzeug, das sich natürlich auf Deutsch bedienen lässt, senkt die Hürde für Nutzer und macht den praktischen Einsatz angenehmer.
4. Eine offene Lizenz
Qwen3 14B steht unter der Apache-2.0-Lizenz. Damit lässt sich das Modell für unseren Anwendungsfall ohne zusätzlichen Registrierungsprozess einsetzen.
Was ein lokales Modell gut kann
Nach mehreren Wochen praktischer Nutzung zeigt sich ein klares Bild.
Natürliche Sprache in konkrete Aktionen übersetzen
Das ist die größte Stärke.
Eine Anfrage wie
„Kopier mir den Supabase-Key“
kann vom Modell in die notwendigen Schritte übersetzt werden: Eintrag suchen, passenden Eintrag auswählen und anschließend die gewünschte Aktion ausführen.
Auch komplexere Anweisungen funktionieren:
„Übernimm aus der env-Datei nur DATABASE_URL und STRIPE_SECRET_KEY.“
Das Modell kann daraus einen strukturierten Import mit den gewünschten Variablen ableiten.
Entscheidend ist dabei, dass der Werkzeugkasten überschaubar bleibt. In unserem Fall stehen dem Modell elf klar definierte Werkzeuge zur Verfügung.
Je klarer die möglichen Aktionen beschrieben sind, desto zuverlässiger kann das Modell zwischen ihnen unterscheiden.
Schnell genug für den Alltag
Auf der GPU reagiert das Modell innerhalb weniger Sekunden.
Nach längeren Pausen kann es etwas länger dauern, weil das Modell zunächst wieder in den Grafikspeicher geladen werden muss. Im normalen Arbeitsablauf ist dieser Effekt jedoch kaum störend.
Damit zeigt sich ein wichtiger Punkt: Lokale KI muss nicht zwangsläufig langsam sein. Mit passender Hardware und einem entsprechend dimensionierten Modell kann sie sich sehr direkt bedienen lassen.
Unscharfe Fragen verstehen
Menschen formulieren nicht immer exakt so, wie eine Datenbank es erwartet.
Eine Frage wie
„Wie lauten die letzten 4 Zeichen vom mistral-dev key?“
kann das Modell trotzdem dem richtigen Eintrag zuordnen – auch wenn Schreibweise, Bindestriche oder die genaue Formulierung variieren.
Das ist ein wesentlicher Vorteil gegenüber einer rein textbasierten Suche.
Lokale Verarbeitung
Ein weiterer Vorteil liegt in der Architektur.
Das Sprachmodell läuft lokal auf dem Rechner. Die Verarbeitung der Anfrage findet damit dort statt, wo auch die sensiblen Informationen liegen.
Für Anwendungen, bei denen Datenschutz und Kontrolle über sensible Daten besonders wichtig sind, ist das ein grundsätzlich interessanter Ansatz.
Wo die Grenzen liegen
Noch interessanter als die Stärken sind die Situationen, in denen das Modell Fehler macht.
Denn ein Sprachmodell ist kein klassisches Programm. Es arbeitet nicht ausschließlich mit festen Regeln, sondern erzeugt auf Basis seiner Eingaben die wahrscheinlichste passende Antwort bzw. Aktion.
Das kann zu überraschenden Ergebnissen führen.
Sprachmodelle können Details erfinden
Nach einem erfolgreichen Import meldete das Modell beispielsweise konkrete IDs für neu angelegte Einträge.
Das Problem: Diese IDs waren gar nicht Bestandteil der Rückgabe des verwendeten Werkzeugs.
Das Modell hatte sie also nicht aus den tatsächlichen Daten abgelesen – es hatte sie ergänzt.
Warum passiert so etwas?
Ein Sprachmodell versucht, eine plausible und vollständige Antwort zu formulieren. Wenn Informationen fehlen, kann es passieren, dass es diese Lücke mit einer scheinbar passenden Information füllt.
Die entscheidende Erkenntnis lautet deshalb:
Ein Modell darf niemals als Quelle für Informationen betrachtet werden, die es nicht tatsächlich erhalten hat.
Wenn eine Information relevant ist, muss sie explizit aus der Anwendung an das Modell übergeben werden.
Ähnliche Absichten können verwechselt werden
Noch kritischer wird es bei Aktionen mit Nebenwirkungen.
Eine Anweisung wie
„Entferne alle Secrets, behalte die Key-Namen“
kann unterschiedlich interpretiert werden.
In unserem Fall war eigentlich gemeint, die Werte in einem eingefügten Text zu schwärzen. Aufgrund eines Fehlers in der Eingabeverarbeitung erhielt das Modell jedoch nicht den vollständigen Kontext.
Es interpretierte die Anfrage deshalb als Aufforderung, Einträge aus dem Tresor zu entfernen.
Das zeigt ein grundlegendes Prinzip:
Ein Sprachmodell kann eine falsche Interpretation sehr überzeugend vertreten.
Deshalb dürfen sicherheitsrelevante Aktionen nicht allein davon abhängen, ob das Modell eine Anfrage richtig verstanden hat.
Für kritische Aktionen braucht es zusätzliche technische Schutzmechanismen – beispielsweise Bestätigungen, Plausibilitätsprüfungen und Limits für wiederholte Aktionen.
Die Suche muss mit Unschärfe umgehen können
Auch die Suchfunktion selbst musste angepasst werden.
Unsere ursprüngliche Suche erwartete einen relativ exakt passenden Suchbegriff. Das Modell übergab jedoch je nach Anfrage beispielsweise:
mistral-devmistral-dev key- die komplette Nutzerfrage
Für den Nutzer sah das zunächst nach einem unzuverlässigen Modell aus.
Tatsächlich lag das Problem aber teilweise in unserer Suche.
Die Lösung war, die Suchlogik robuster zu machen: Suchbegriffe werden in einzelne Bestandteile zerlegt und Treffer entsprechend gewichtet.
Das ist eine wichtige Erkenntnis für KI-Anwendungen:
Nicht jede Ungenauigkeit sollte man dem Modell überlassen. Oft ist es besser, die Software rund um das Modell fehlertoleranter zu machen.
Ein lokales Modell ist keine Sicherheitsgrenze
Der vielleicht wichtigste Punkt des gesamten Projekts:
Lokal bedeutet nicht automatisch sicher.
Ein Sprachmodell kann beispielsweise Text aus einer Datenbank oder Datei erhalten, der selbst Anweisungen enthält.
Steht dort etwa sinngemäß:
„Ignoriere die bisherigen Anweisungen.“
kann ein Modell versuchen, diesen Text bei seiner Entscheidung zu berücksichtigen.
Das Problem ist nicht dadurch gelöst, dass das Modell lokal läuft.
Deshalb liegt die Sicherheitsarchitektur unseres Tresors nicht darin, dass das Sprachmodell immer korrekt oder „brav“ reagiert.
Die Sicherheitsmechanismen liegen außerhalb des Modells:
- Schreibende Aktionen werden vor der Ausführung bestätigt.
- Das Modell kann kritische Aktionen lediglich vorschlagen.
- Sensible Werte werden nicht unnötig in den Gesprächskontext übernommen.
- Kritische Abläufe werden automatisiert überprüft.
- Wiederholte oder ungewöhnliche Aktionen werden begrenzt.
- Ein großer Teil des Codes dient ausdrücklich der Verifikation.
Von insgesamt 2.951 Codezeilen sind beispielsweise 487 Zeilen der Verifikation und 51 konkreten Prüfungen gewidmet, die bei jedem Build ausgeführt werden.
Das Prinzip dahinter ist einfach:
Das Modell darf bei der Bedienung helfen. Die Anwendung entscheidet, was tatsächlich passieren darf.
Warum das Modell keinen Netzzugang benötigt
Wir haben bewusst darauf verzichtet, dem Modell Zugriff auf das Internet zu geben.
Dadurch kann es beispielsweise nicht selbst überprüfen, ob ein bestimmter API-Key beim jeweiligen Anbieter noch gültig ist.
Für einen Schlüsseltresor ist das jedoch keine notwendige Funktion.
Im Gegenteil: Jeder zusätzliche externe Datenzugriff eröffnet eine weitere Schnittstelle zwischen dem Modell und fremden Inhalten.
Für unsere Anwendung ist deshalb ein klar begrenzter Funktionsumfang sinnvoller: Das Modell kann die lokal verfügbaren Werkzeuge nutzen, aber nicht eigenständig auf externe Dienste zugreifen.
Was wir aus dem Projekt mitnehmen
Nach der praktischen Erprobung lassen sich vier Punkte festhalten.
1. Lokale Modelle sind für klar abgegrenzte Aufgaben bereits gut genug
Ein Modell mit rund 14 Milliarden Parametern kann auf einer handelsüblichen Grafikkarte anspruchsvolle Aufgaben übernehmen.
Voraussetzung ist allerdings ein klar definierter Anwendungsfall.
Kurze Anfragen, ein überschaubarer Werkzeugkasten und klar beschriebene Aktionen sind eine gute Kombination.
2. Die eigentliche Arbeit steckt in der Architektur
Die Auswahl des Modells war nur ein Teil des Projekts.
Mindestens genauso wichtig waren:
- robuste Werkzeuge,
- eine fehlertolerante Suche,
- klare Bestätigungsdialoge,
- Eingabevalidierung,
- Sicherheitsprüfungen,
- Tests und Verifikationen.
Das Modell ist also nur eine Komponente.
Die Qualität eines KI-Systems entsteht vor allem durch das Zusammenspiel aus Modell und Software, die es kontrolliert.
3. Der größte Vorteil ist die Kontrolle über sensible Daten
Geschwindigkeit und Kosten sind interessante Nebeneffekte.
Der entscheidende Vorteil lokaler Verarbeitung liegt jedoch woanders:
Sensible Informationen müssen den eigenen Rechner nicht verlassen, damit ein Sprachmodell damit arbeiten kann.
Diese Eigenschaft lässt sich nicht nachträglich in eine Anwendung hineinreden. Sie muss bereits in der Architektur berücksichtigt werden.
4. „Lokal“ sollte man wörtlich nehmen
Zum Schluss gab es noch eine Erkenntnis, die zunächst gar nichts mit dem Sprachmodell zu tun hatte.
Bei der Überprüfung des Systems zeigte sich, dass bestimmte Ordner wie „Dokumente“ und „Desktop“ auf dem Rechner in einen Firmen-OneDrive umgeleitet waren.
Eine Datei, die vermeintlich „lokal“ gespeichert wird, kann dadurch trotzdem automatisch synchronisiert werden.
Wer sensible Daten lokal halten möchte, sollte deshalb nicht nur auf die Anwendung schauen, sondern auch prüfen, wo Dateien auf dem eigenen System tatsächlich gespeichert und synchronisiert werden.
Fazit
Ein lokales Sprachmodell ist kein magischer KI-Agent, der beliebige Aufgaben zuverlässig und autonom erledigen kann.
Aber das muss es auch nicht sein.
Für einen klar definierten Anwendungsfall kann bereits ein vergleichsweise kleines Modell erstaunlich viel leisten. Es kann natürliche Sprache verstehen, daraus strukturierte Aktionen ableiten und die Bedienung komplexerer Software deutlich vereinfachen.
Die wichtigste Erkenntnis aus unserem Projekt ist deshalb weniger die Wahl des konkreten Modells als die Architektur darum herum:
Das Sprachmodell interpretiert die Anfrage. Die Software kontrolliert die Ausführung.
Genau diese Trennung macht es möglich, die Vorteile natürlicher Sprache zu nutzen, ohne sicherheitskritische Entscheidungen vollständig an ein Sprachmodell abzugeben.
Und sie zeigt zugleich, wo lokale KI heute besonders interessant ist: bei kleinen, klar abgegrenzten Aufgaben, bei denen Datenschutz, Kontrolle und lokale Verarbeitung wichtiger sind als maximale Modellgröße.