Lokale KI selbst betreiben: RAG, Hosting und Datenschutz

Lokale KI bedeutet inzwischen deutlich mehr als einen Chatbot, der ohne Internet auf dem eigenen Rechner läuft. Sprachmodelle können mit internen Dokumenten arbeiten, Daten aus bestehenden Systemen abrufen, Anfragen einordnen und zusammen mit Sprach- oder Automatisierungsdiensten komplette Abläufe unterstützen.

Dafür muss nicht jede Komponente auf demselben Computer liegen. Ein Modell kann auf eigener Hardware ausgeführt werden, auf einem selbst verwalteten Server in einem Rechenzentrum oder über eine gemanagte Infrastruktur, bei der Standort und Datenverarbeitung gezielter festgelegt werden können.

Gleichzeitig braucht nicht jede dieser Aufgaben eines der größten verfügbaren Sprachmodelle. Wenn der Anwendungsfall klar begrenzt ist und benötigtes Fachwissen aus externen Datenquellen zugeliefert wird, können kleinere Modelle ausreichen.

Dieser Beitrag zeigt, welche technischen Varianten es gibt, welche Rolle Retrieval Augmented Generation spielt, wann Fine-Tuning sinnvoll ist und warum ein Server in Deutschland allein noch keine datenschutzkonforme KI-Anwendung garantiert.

Was bedeutet lokale KI überhaupt?

Im engsten Sinn läuft lokale KI vollständig auf einem Gerät oder innerhalb des eigenen Netzwerks. Eingaben werden dort verarbeitet und das Modell erzeugt seine Ausgabe, ohne für die eigentliche Inferenz einen externen Modelldienst aufzurufen.

In der Praxis wird der Begriff allerdings häufig weiter verwendet. Ein Unternehmen kann ein Modell beispielsweise selbst verwalten, obwohl die Hardware physisch in einem Rechenzentrum steht. Technisch ist das nicht mehr lokal im Sinn von „auf dem eigenen Rechner“, die Kontrolle über Modell, Software und Datenfluss kann aber trotzdem deutlich größer sein als bei einem öffentlichen KI-Dienst.

Eigener Rechner
      |
      v
Eigenes Netzwerk
      |
      v
Selbst verwalteter Server im Rechenzentrum
      |
      v
Gemanagter Modelldienst
      |
      v
Öffentlicher KI-Dienst

Zwischen diesen Varianten gibt es keinen harten technischen Schnitt. Mit jedem Schritt kann mehr Betriebsaufwand an einen Dienstleister abgegeben werden. Gleichzeitig verändert sich, welche Teile der Infrastruktur selbst kontrolliert werden.

Wo kann ein Sprachmodell betrieben werden?

1. Auf dem eigenen Rechner

Für Tests, interne Werkzeuge oder Anwendungen mit moderaten Anforderungen kann ein Modell direkt auf einem Arbeitsplatzrechner oder einer Workstation laufen. Modellgewichte, Prompts und Ausgaben können dabei vollständig auf dem Gerät bleiben, sofern keine zusätzlichen externen Dienste eingebunden werden.

Die Grenzen entstehen vor allem durch verfügbaren Arbeitsspeicher beziehungsweise Grafikspeicher, Speicherbandbreite und Rechenleistung. Kleinere und quantisierte Modelle senken diese Anforderungen, erreichen aber nicht automatisch die gleiche Qualität wie größere Modelle.

2. Auf einem eigenen Server im lokalen Netzwerk

Wenn mehrere Nutzer oder Anwendungen auf dieselbe KI zugreifen sollen, kann ein zentraler Server im eigenen Netzwerk sinnvoller sein. Das Sprachmodell wird dort einmal bereitgestellt und verschiedene Anwendungen greifen über eine interne Schnittstelle darauf zu.

Mitarbeiter
Anwendung
Automatisierung
     |
     v
Interne Modell-Schnittstelle
     |
     v
Eigener KI-Server

Damit lässt sich die Modellschicht von den einzelnen Anwendungen trennen. Ein späterer Modellwechsel muss dann nicht zwangsläufig jede Anwendung verändern.

3. Auf einem selbst verwalteten Server im Rechenzentrum

Ein selbst verwalteter KI-Server muss nicht im eigenen Gebäude stehen. Rechenzentren vermieten Hardware mit leistungsfähigen GPUs, auf der eigene Modelle und Anwendungen betrieben werden können.

Der physische Standort der Hardware ist dann ausgelagert, während Betriebssystem, Modellserver, Zugriffsregeln und die eigentliche Anwendung weiterhin selbst verwaltet werden können. Für größere Modelle entfällt damit die Anschaffung eigener GPU-Hardware, allerdings bleibt der technische Betriebsaufwand bestehen.

4. Über einen gemanagten Modelldienst

Bei einem gemanagten Modelldienst betreibt ein Anbieter die Modellinfrastruktur und stellt eine Schnittstelle für Anfragen bereit. Je nach Angebot können Region, verwendetes Modell, Speicherregeln und vertragliche Bedingungen festgelegt werden.

Diese Variante ähnelt aus Sicht der Anwendung einer gewöhnlichen KI-API. Der Unterschied liegt darin, dass Infrastruktur und Datenverarbeitung gezielter ausgewählt werden können als bei einem beliebigen öffentlichen Chatbot.

Die Betriebsmodelle im Vergleich

Variante	Eigene Kontrolle	Eigener Betriebsaufwand	Typischer Vorteil
Modell auf eigenem Rechner	sehr hoch	mittel	Daten und Modell können vollständig lokal bleiben
Eigener Server im Netzwerk	sehr hoch	hoch	zentrale KI für mehrere interne Anwendungen
Selbst verwalteter Server im Rechenzentrum	hoch	hoch	mehr Hardwareleistung ohne eigene Server vor Ort
Gemanagter Modelldienst	abhängig vom Vertrag und Dienst	niedriger	weniger Infrastrukturverwaltung
Öffentlicher KI-Dienst	abhängig vom Anbieter	sehr niedrig	schneller Einstieg und große Modellauswahl

Die Tabelle ist bewusst vereinfacht. Entscheidend ist nicht nur, wo der Modellprozess läuft, sondern auch wo Protokolle, Dokumente, Vektordatenbanken, Audiodaten und andere angebundene Systeme verarbeitet werden.

Warum für viele Aufgaben kleinere Modelle ausreichen können

Ein allgemeiner KI-Assistent soll möglichst viele unterschiedliche Aufgaben erledigen. Er soll programmieren, Texte schreiben, Bilder verstehen, Wissen abrufen und komplexe Fragen beantworten. Dafür sind sehr leistungsfähige Modelle sinnvoll.

Ein Modell innerhalb eines klar definierten Prozesses hat häufig eine deutlich kleinere Aufgabe. Es soll vielleicht nur erkennen, ob eine Nachricht eine Reklamation, eine Terminfrage oder eine Bestellung betrifft. Oder es soll Informationen aus vorgegebenen Dokumenten zusammenfassen und in ein festes Format übertragen.

Für solche Aufgaben ist nicht entscheidend, ob das Modell in jedem allgemeinen Benchmark zu den besten Modellen gehört. Wichtiger ist, ob es die konkrete Aufgabe zuverlässig ausführt und mit den richtigen Daten versorgt wird.

Allgemeiner Assistent
  |
  + Programmieren
  + Mathematik
  + Schreiben
  + Bildverständnis
  + Allgemeinwissen
  + Recherche

Spezialisierter Prozess
  |
  + Anfrage verstehen
  + passende Daten abrufen
  + definierte Ausgabe erzeugen

Dadurch kann es sinnvoll sein, einfache und häufige Aufgaben mit einem kleineren Modell zu bearbeiten und nur schwierige Fälle an ein stärkeres Modell oder einen Menschen weiterzugeben.

RAG: Wissen muss nicht im Modell gespeichert sein

Viele Anwendungen benötigen aktuelles oder internes Wissen. Produktdaten, technische Dokumentationen, Richtlinien oder Kundendaten ändern sich regelmäßig und eignen sich deshalb schlecht als Wissen, das dauerhaft in ein Sprachmodell eingebaut werden soll.

Bei Retrieval Augmented Generation, kurz RAG, bleibt dieses Wissen außerhalb des Modells. Bevor das Sprachmodell antwortet, sucht das System passende Informationen aus einer Datenquelle heraus und gibt nur die relevanten Inhalte zusammen mit der eigentlichen Anfrage an das Modell.

Frage
  |
  v
Suche in Dokumenten oder Datenbank
  |
  v
Relevante Textstellen
  |
  v
Sprachmodell
  |
  v
Antwort mit bereitgestelltem Kontext

Die Datenschutzkonferenz beschreibt RAG als Verfahren, bei dem Sprachmodelle gezielt um unternehmens- oder behördeneigene Wissensquellen ergänzt werden. In ihrer Orientierungshilfe weist sie auch darauf hin, dass RAG kleinere und lokal betriebene Modelle ermöglichen kann.

Auch die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit nennt zwei praktische Vorteile. Informationen in einem RAG-System lassen sich leichter verändern oder löschen als Wissen, das in einem Modell steckt. Außerdem können kleinere Sprachmodelle ausreichen, wenn relevante Informationen durch die Datenbank zugeliefert werden.

Warum RAG für veränderliche Daten sinnvoll ist

Ändert sich beispielsweise morgen eine technische Vorgabe, wird die entsprechende Information in der Datenquelle aktualisiert. Das Sprachmodell muss deshalb nicht neu trainiert werden.

Bei der nächsten Anfrage sucht das System bereits die neue Version heraus.

Dokument Version 1
      |
   Änderung
      |
      v
Dokument Version 2
      |
      v
RAG Suche
      |
      v
Aktuelle Information für das Modell

RAG garantiert allerdings keine korrekten Antworten. Wenn die falschen Dokumente gefunden werden, die Datenquelle veraltet ist oder das Modell den gelieferten Kontext falsch interpretiert, können weiterhin Fehler entstehen.

Muss ein eigenes KI-Modell trainiert werden?

Für viele spezialisierte Anwendungen muss kein Sprachmodell von Grund auf trainiert werden. Das Training eines Grundlagenmodells erfordert große Datenmengen und erhebliche Rechenleistung und ist für gewöhnliche Unternehmensanwendungen normalerweise nicht der sinnvolle Ausgangspunkt.

In der Praxis werden mehrere unterschiedliche Methoden häufig miteinander verwechselt.

Methode	Wofür sie gedacht ist	Ändert das Modell selbst?
Prompting	Aufgabe, Regeln und gewünschte Ausgabe beschreiben	Nein
RAG	Aktuelles oder internes Wissen zur Anfrage hinzufügen	Nein
Fine-Tuning	Verhalten für wiederkehrende Aufgaben gezielt anpassen	Ja
Training von Grund auf	Ein neues Grundlagenmodell erzeugen	Ja, vollständig

Wenn ein Modell beispielsweise interne Dokumente kennen soll, ist RAG häufig naheliegender als Fine-Tuning. Wenn dagegen immer wieder dieselbe Klassifikation, Struktur oder Ausdrucksweise benötigt wird, kann Fine-Tuning sinnvoll sein.

Beide Verfahren können auch kombiniert werden. Das angepasste Modell kümmert sich dann um das gewünschte Verhalten, während aktuelle Informationen weiterhin aus externen Datenquellen kommen.

Wie aus einem Sprachmodell ein vollständiges KI-System wird

Ein Sprachmodell allein kann zunächst Text entgegennehmen und Text erzeugen. Für reale Prozesse braucht es zusätzliche Komponenten.

Ein System zur Bearbeitung von Anfragen könnte beispielsweise so aufgebaut sein:

E-Mail
Webformular
Telefon
   |
   v
Text oder Spracherkennung
   |
   v
Anfrage analysieren
   |
   +----> Dokumente
   +----> CRM
   +----> ERP
   +----> Kalender
   |
   v
Sprachmodell
   |
   v
Antwort oder definierte Aktion

Das Modell muss dabei weder alle Kundendaten noch alle Produktinformationen selbst kennen. Es kann zuerst feststellen, welche Information benötigt wird, und diese anschließend aus dem passenden System erhalten.

Beispiel: eine schriftliche Anfrage

Eine eingehende Nachricht kann zunächst klassifiziert werden. Geht es um eine Bestellung, kann das System die passende Bestellinformation abrufen. Geht es um eine technische Frage, können relevante Abschnitte aus einer Dokumentation gesucht werden.

Das Sprachmodell verarbeitet anschließend nur die Informationen, die für diesen Vorgang benötigt werden.

Beispiel: ein Telefonanruf

Bei Sprache kommen weitere Komponenten hinzu. Die Audiodaten werden zunächst durch eine Spracherkennung in Text umgewandelt. Danach kann ein Sprachmodell die Anfrage verarbeiten. Für eine gesprochene Antwort wird der erzeugte Text anschließend wieder in Sprache umgewandelt.

Anruf
  |
  v
Spracherkennung
  |
  v
Text
  |
  v
Sprachmodell und Datenquellen
  |
  v
Antworttext
  |
  v
Sprachausgabe

Damit kann ein System Telefonate verarbeiten, ohne dass das Sprachmodell selbst Audio verstehen oder erzeugen muss. Die einzelnen Komponenten können unabhängig voneinander ausgewählt und betrieben werden.

Bei Gesprächsaufzeichnungen, Transkriptionen und personenbezogenen Gesprächsinhalten müssen zusätzlich die jeweiligen datenschutzrechtlichen und sonstigen rechtlichen Anforderungen geprüft werden.

Das Modell ist nur eine Komponente des Datenflusses

Bei einer selbst betriebenen KI reicht es nicht, nur den Standort des Sprachmodells zu betrachten. Ein Workflow kann weitere Dienste enthalten, die eigene Datenverbindungen besitzen.

Ein vollständig selbst kontrollierter Aufbau könnte beispielsweise Spracherkennung, Sprachmodell, Dokumentensuche und Datenbank innerhalb derselben Infrastruktur betreiben. Werden einzelne Komponenten durch externe Dienste ersetzt, verlassen entsprechende Daten diesen Bereich.

Dokumente --------+
                  |
CRM --------------+----> eigener KI-Workflow ----> Ausgabe
                  |
Spracherkennung --+

oder

Dokumente --------+
                  |
CRM --------------+----> eigenes Modell
                  |
externer Sprachdienst <---- Audiodaten

Deshalb sollte bei der Architektur für jede Komponente klar sein, welche Daten sie erhält, wo sie verarbeitet werden und ob sie gespeichert oder für andere Zwecke verwendet werden.

Ein Server in Deutschland macht eine KI nicht automatisch DSGVO-konform

Der Standort der Infrastruktur kann für Datenschutz, Vertragsgestaltung und Datenübermittlungen wichtig sein. Er beantwortet aber nicht allein die Frage, ob eine konkrete Verarbeitung zulässig ist.

Entscheidend sind unter anderem Zweck und Rechtsgrundlage der Verarbeitung, Art der verarbeiteten Daten, Zugriffsrechte, Speicherfristen, beteiligte Auftragsverarbeiter und mögliche weitere Empfänger.

Der Europäische Datenschutzausschuss betont bei KI-Modellen ausdrücklich die Einzelfallprüfung. Ob ein Modell als anonym gelten kann oder ob eine bestimmte Rechtsgrundlage trägt, hängt von der konkreten Verarbeitung und den jeweiligen Umständen ab.

Auch RAG löst diese Fragen nicht automatisch. Die Datenschutzkonferenz weist darauf hin, dass Transparenz, Zweckbindung und Betroffenenrechte weiterhin im gesamten System berücksichtigt werden müssen.

Welche Fragen sollten technisch dokumentiert werden?

• Wo läuft das Sprachmodell?
• Wo liegen Dokumente und Vektordatenbank?
• Welche Daten werden an das Modell übergeben?
• Welche externen Dienste sind beteiligt?
• Wer kann auf gespeicherte Eingaben und Ausgaben zugreifen?
• Wie lange werden Protokolle und Zwischendaten gespeichert?
• Welche Aktionen darf das System selbst ausführen?
• Bei welchen Vorgängen muss ein Mensch freigeben?

Diese Fragen sind nicht nur für den Datenschutz nützlich. Sie helfen auch bei Sicherheit, Fehlersuche und späterem Austausch einzelner Komponenten.

Wann ist ein lokales oder selbst kontrolliertes Modell sinnvoll?

Eine eigene oder stärker kontrollierte Infrastruktur kann sinnvoll sein, wenn regelmäßig sensible interne Informationen verarbeitet werden, ein klar begrenzter Prozess automatisiert werden soll oder ein Modell dauerhaft in bestehende Systeme eingebunden wird.

Typische technische Anwendungsfälle sind beispielsweise interne Dokumentenassistenten, Klassifikation und Extraktion von Informationen, Verarbeitung wiederkehrender Anfragen oder Werkzeuge, die innerhalb eines bestehenden Softwareprozesses eingesetzt werden.

Auch ein hybrider Aufbau ist möglich. Ein kleineres eigenes Modell verarbeitet Standardfälle, während außergewöhnlich schwierige Aufgaben an einen stärkeren externen Dienst weitergegeben werden. Welche Daten diesen Weg nehmen dürfen, muss dann ausdrücklich berücksichtigt werden.

Wann ist ein externer Cloud-Dienst weiterhin sinnvoll?

Selbst betriebene KI ist nicht automatisch die bessere Lösung. Sehr große Modelle, aufwendige Bild- und Videogenerierung oder stark schwankende Last können in einer Cloud wirtschaftlicher und technisch einfacher sein.

Hinzu kommt der Betriebsaufwand. Eigene Modelle müssen aktualisiert, überwacht und abgesichert werden. Hardware kann ausfallen, Modellversionen ändern sich und neue Sicherheitslücken müssen berücksichtigt werden.

Die Entscheidung ist deshalb kein einfaches „lokal oder Cloud“. Häufig ist die bessere Frage, welche Komponenten eines Systems selbst kontrolliert werden müssen und bei welchen Komponenten ein externer Dienst akzeptabel ist.

Wie würde ich einen Prototypen aufbauen?

Für einen ersten Test würde ich nicht versuchen, sofort ein vollständiges KI-System mit Telefonie, Dokumentensuche und mehreren Unternehmensanwendungen zu bauen.

Zuerst sollte eine einzige, klar begrenzte Aufgabe geprüft werden. Dafür kann ein kleines Modell mit einer begrenzten Datenquelle verbunden werden.

Reale Beispielanfragen
        |
        v
Kleine Dokumentensammlung
        |
        v
RAG
        |
        v
Sprachmodell
        |
        v
Testbare Antwort

Erst wenn klar ist, dass die Aufgabe zuverlässig funktioniert, werden weitere Datenquellen oder Aktionen angebunden. Dadurch lassen sich Modellqualität, Retrieval und Prozesslogik getrennt bewerten.

Die Anwendung sollte das verwendete Modell möglichst über eine eigene interne Schnittstelle ansprechen. Dadurch kann später ein lokales Modell gegen einen Server oder einen anderen Modelldienst ausgetauscht werden, ohne die gesamte Anwendung neu zu entwickeln.

Anwendung
    |
    v
Eigener Model Adapter
    |
    +----> lokales Modell
    |
    +----> eigener Server
    |
    +----> externer Modelldienst

Damit bleibt die Architektur flexibel, während die eigentliche Fachlogik unabhängig vom gerade verwendeten Modell entwickelt werden kann.

Fazit

Lokale KI ist heute nicht mehr auf einen einfachen Offline-Chatbot beschränkt. Sprachmodelle können Teil größerer Systeme sein, die Dokumente durchsuchen, Daten aus bestehenden Anwendungen abrufen, Sprache verarbeiten und definierte Aktionen vorbereiten oder ausführen.

Für klar abgegrenzte Aufgaben muss dabei nicht immer eines der größten Modelle eingesetzt werden. RAG kann aktuelles Fachwissen von außen bereitstellen und dadurch kleinere Modelle praktikabler machen. Fine-Tuning ist eine zusätzliche Option, wenn nicht das Wissen, sondern das Verhalten des Modells gezielt angepasst werden soll.

Ob ein System auf eigener Hardware, einem gemieteten Server oder einer gemanagten Infrastruktur läuft, ist letztlich eine Architekturentscheidung. Der Standort beeinflusst Kontrolle und mögliche Datenflüsse, ersetzt aber keine Prüfung der konkreten Verarbeitung.

Wenn Sie prüfen möchten, ob sich ein eigener oder stärker kontrollierter KI-Workflow für einen bestehenden Prozess eignet, ist ein kleiner Prototyp meist aussagekräftiger als eine allgemeine Modellentscheidung.

In 15 Minuten lässt sich unverbindlich klären, welche Architektur zu Ihren Daten, vorhandenen Systemen und Anforderungen passt. Zum Erstgespräch.