Lokale KI im Unternehmen: Was heute schon möglich ist

Lokale KI wird häufig noch mit einem einzelnen Sprachmodell auf einem leistungsfähigen PC gleichgesetzt. Für reale Anwendungen ist diese Vorstellung inzwischen zu klein.

Ein KI-System kann heute E-Mails einordnen, interne Dokumente durchsuchen, Informationen aus CRM- oder ERP-Systemen abrufen und sogar Sprachkanäle verarbeiten. Das eigentliche Sprachmodell ist dabei nur eine Komponente. Entscheidend ist, wie Modell, Datenquellen, Werkzeuge und Infrastruktur zusammenspielen.

Gleichzeitig muss eine solche Lösung nicht vollständig im eigenen Gebäude laufen. Zwischen einem Modell auf dem Laptop und einem öffentlichen Cloud-Dienst gibt es mehrere Betriebsformen, bei denen unterschiedlich viel Kontrolle und technischer Aufwand beim Unternehmen bleiben.

Dieser Beitrag zeigt, wie lokale beziehungsweise kontrolliert betriebene KI heute aufgebaut werden kann, warum kleinere Modelle für klar definierte Aufgaben oft ausreichen und welche Rolle RAG, Fine-Tuning und Datenschutz dabei spielen.

Lokale KI ist kein einzelnes Betriebsmodell

Im engsten Sinn bedeutet lokale KI, dass ein Modell direkt auf dem eigenen Rechner oder innerhalb des eigenen Netzwerks läuft. Eingaben und Ausgaben müssen für die eigentliche Modellverarbeitung dann keinen externen KI-Dienst erreichen.

Für Unternehmen ist jedoch häufig nicht nur der physische Standort relevant. Ebenso wichtig ist, wer die Infrastruktur kontrolliert, welche Daten das System verlassen und welche Komponenten von externen Anbietern betrieben werden.

Dadurch entsteht ein Spektrum verschiedener Architekturen.

Betriebsform	Wo läuft das Modell?	Eigene Kontrolle	Betriebsaufwand
Lokaler Rechner	Arbeitsplatz oder Workstation	sehr hoch	mittel
Eigener Server	Unternehmensnetzwerk	sehr hoch	hoch
Selbst verwalteter Server	Rechenzentrum	hoch	hoch
Gemanagte Modellinfrastruktur	gewähltes Rechenzentrum oder Region	abhängig vom Dienst	niedriger
Öffentlicher KI-Dienst	Infrastruktur des Anbieters	abhängig vom Anbieter	sehr niedrig

Keine dieser Varianten ist automatisch die richtige. Ein interner Dokumentenassistent hat andere Anforderungen als ein System, das mehrere Abteilungen, Kundenkanäle und Unternehmensanwendungen miteinander verbindet.

Das Sprachmodell ist nur ein Baustein

Ein nacktes Sprachmodell nimmt Text entgegen und erzeugt Text. Erst durch zusätzliche Datenquellen und Werkzeuge wird daraus ein System, das in einem realen Prozess arbeiten kann.

Ein vereinfachter Aufbau könnte so aussehen:

E-Mail
Webformular
Telefon
interne Anwendung
      |
      v
Eingabe aufbereiten
      |
      v
Sprachmodell
      |
      +---- Dokumentensuche
      +---- CRM
      +---- ERP
      +---- Kalender
      +---- andere interne APIs
      |
      v
Antwort, Klassifikation
oder definierte Aktion

Das Modell muss dabei nicht sämtliche Informationen selbst enthalten. Es kann zunächst erkennen, welche Information für eine Anfrage benötigt wird, und diese anschließend aus dem passenden System beziehen.

Damit verschiebt sich die technische Aufgabe. Statt ein möglichst allwissendes Modell zu bauen, wird der Prozess in kleinere Komponenten zerlegt.

Warum kleinere Modelle oft ausreichen können

Große allgemeine Modelle müssen möglichst viele unterschiedliche Aufgaben beherrschen. Sie sollen Texte schreiben, programmieren, Bilder verstehen, Wissen verarbeiten und komplexe Probleme lösen.

Ein Modell innerhalb eines klar begrenzten Unternehmensprozesses hat häufig einen wesentlich kleineren Aufgabenbereich. Es soll beispielsweise nur erkennen, um welche Art von Anfrage es sich handelt, einige Informationen aus vorgegebenen Quellen verarbeiten und daraus eine strukturierte Antwort erzeugen.

In solchen Fällen ist die allgemeine Modellgröße nicht das einzige relevante Kriterium.

Allgemeines Modell
      |
      +---- Programmieren
      +---- Schreiben
      +---- Analyse
      +---- Mathematik
      +---- Bildverständnis
      +---- Allgemeinwissen


Spezialisierter Prozess
      |
      +---- Anfrage verstehen
      +---- Daten abrufen
      +---- Regeln anwenden
      +---- Ergebnis erzeugen

Ein kleineres Modell kann dadurch für eine konkrete Aufgabe ausreichend sein, obwohl es in allgemeinen Benchmarks hinter größeren Modellen liegt.

Das bedeutet nicht, dass kleinere Modelle grundsätzlich gleich leistungsfähig sind. Bei mehrdeutigen, seltenen oder komplexen Fällen kann ein stärkeres Modell weiterhin deutlich bessere Ergebnisse liefern.

Eine mögliche Architektur besteht deshalb darin, Standardfälle mit einem kleineren Modell zu bearbeiten und schwierige Fälle an ein leistungsfähigeres Modell oder einen Menschen weiterzugeben.

RAG: Unternehmenswissen muss nicht in das Modell trainiert werden

Eine der häufigsten Fehlvorstellungen bei eigener KI lautet, dass sämtliche internen Informationen zunächst in ein Modell „hineintrainiert“ werden müssten.

Für viele Anwendungen ist genau das nicht notwendig.

Bei Retrieval Augmented Generation, kurz RAG, bleiben Dokumente und andere Wissensquellen außerhalb des Sprachmodells. Vor der eigentlichen Antwort sucht das System passende Informationen heraus und gibt nur die relevanten Inhalte zusammen mit der Anfrage an das Modell.

Frage
  |
  v
Suche in eigenen Daten
  |
  v
passende Informationen
  |
  v
Sprachmodell
  |
  v
Antwort auf Basis
des bereitgestellten Kontexts

Das ist insbesondere bei Informationen sinnvoll, die sich regelmäßig ändern. Wird eine Produktbeschreibung, interne Richtlinie oder technische Dokumentation aktualisiert, muss kein Sprachmodell neu trainiert werden. Die neue Information steht beim nächsten Abruf direkt zur Verfügung.

Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit weist in ihrer KI-Handreichung darauf hin, dass RAG unter anderem kleinere Sprachmodelle ermöglichen kann, weil relevante Informationen aus einer Datenbank zugeliefert werden. Informationen außerhalb des Modells lassen sich außerdem einfacher verändern oder löschen als Wissen, das bereits in einem Modell enthalten ist.

RAG ist keine automatische Garantie für richtige Antworten

Ein RAG-System löst allerdings nicht jedes Qualitätsproblem.

Wenn die falschen Dokumente gefunden werden, die Datenquelle veraltet ist oder das Modell den gelieferten Kontext falsch interpretiert, kann die Antwort weiterhin falsch sein.

Die Qualität hängt deshalb nicht nur vom Sprachmodell ab. Ebenso wichtig sind die Qualität der Dokumente, die Suchlogik und die Frage, wie zuverlässig relevante Informationen aus der Datenbasis gefunden werden.

Wann ist Fine-Tuning sinnvoll?

RAG und Fine-Tuning lösen unterschiedliche Probleme.

RAG liefert dem Modell Wissen, das sich außerhalb des Modells befindet. Fine-Tuning verändert dagegen das Verhalten des Modells selbst.

Methode	Typischer Zweck	Ändert das Modell?
Prompting	Aufgabe und Regeln beschreiben	nein
RAG	aktuelle oder interne Informationen bereitstellen	nein
Fine-Tuning	Verhalten für wiederkehrende Aufgaben anpassen	ja
Training von Grund auf	neues Grundlagenmodell erstellen	ja, vollständig

Wenn ein Modell beispielsweise immer wieder dieselbe Art von Dokument klassifizieren oder ein bestimmtes Ausgabeformat besonders zuverlässig erzeugen soll, kann Fine-Tuning sinnvoll sein.

Wenn dagegen aktuelle Unternehmensdaten benötigt werden, ist RAG häufig die passendere Lösung. Beide Verfahren lassen sich auch kombinieren.

Beispiel: Kundenanfragen aus mehreren Kanälen

Ein gutes Beispiel für die Kombination dieser Bausteine ist ein System, das Kundenanfragen aus mehreren Eingangskanälen verarbeitet.

Die KI muss dabei nicht zwangsläufig selbst jede Antwort vollständig kennen. Sie kann zunächst bestimmen, worum es bei einer Anfrage geht, und anschließend die benötigten Informationen aus bestehenden Systemen holen.

Kundenanfrage
      |
      v
Thema erkennen
      |
      +---- Bestellung
      +---- Rechnung
      +---- Support
      +---- Termin
      |
      v
passendes System abfragen
      |
      v
Antwort vorbereiten
oder Vorgang weiterleiten

Bei einer Lieferanfrage kommt der aktuelle Status beispielsweise aus dem Bestell- oder ERP-System. Bei einer technischen Frage können relevante Dokumentationsabschnitte über RAG bereitgestellt werden.

Das Sprachmodell verarbeitet dadurch Informationen, die zum jeweiligen Zeitpunkt aktuell aus den Fachsystemen kommen.

Wie Telefonanrufe in denselben Prozess eingebunden werden können

Telefonie erweitert den Aufbau um zwei zusätzliche Komponenten.

Die Sprache des Anrufers wird zunächst in Text umgewandelt. Danach kann das Sprachmodell denselben Prozess verwenden wie bei einer schriftlichen Anfrage. Eine gesprochene Antwort lässt sich anschließend wieder aus Text erzeugen.

Anruf
  |
  v
Spracherkennung
  |
  v
Text
  |
  v
Sprachmodell
  |
  +---- interne Daten
  +---- Dokumente
  +---- Werkzeuge
  |
  v
Antworttext
  |
  v
Sprachausgabe

Dadurch muss nicht ein einzelnes Modell gleichzeitig Telefonie, Unternehmenswissen und Prozesslogik beherrschen. Die einzelnen Aufgaben können von spezialisierten Komponenten übernommen werden.

Lokale KI bedeutet nicht automatisch vollständig offline

Sobald ein KI-System mehrere Komponenten verwendet, reicht die Frage nach dem Standort des Sprachmodells allein nicht mehr aus.

Ein lokal ausgeführtes Modell kann beispielsweise mit einem externen Spracherkennungsdienst, einer Cloud-Datenbank oder einer Websuche verbunden sein. In diesem Fall bleibt zwar die eigentliche Modellausführung lokal, andere Daten verlassen aber weiterhin die eigene Infrastruktur.

Für die Architektur sollte deshalb jede Komponente einzeln betrachtet werden.

Komponente	Möglicher Standort	Mögliche Daten
Sprachmodell	lokal, eigener Server oder externer Dienst	Prompt, Kontext, Ausgabe
Dokumentensuche	lokal oder externe Datenbank	interne Dokumente, Embeddings
Spracherkennung	lokal oder externer Dienst	Audiodaten, Transkript
CRM oder ERP	intern oder Cloud	Kunden- und Geschäftsdaten
Monitoring	intern oder extern	Logs, Fehlerdaten, Nutzungsdaten

Ein System ist deshalb nur dann vollständig lokal, wenn auch die relevanten Datenquellen, Werkzeuge und Hilfsdienste innerhalb der kontrollierten Infrastruktur bleiben.

Ein Server in Deutschland löst die Datenschutzfrage nicht allein

Der Standort eines Servers kann für Datenschutz und Datenübermittlungen wichtig sein. Er macht eine Anwendung aber nicht automatisch DSGVO-konform.

Entscheidend bleiben unter anderem der Zweck der Verarbeitung, die Rechtsgrundlage, die Art der personenbezogenen Daten, Zugriffsrechte, Speicherfristen und die beteiligten Dienstleister.

Der Europäische Datenschutzausschuss betont bei der Verarbeitung personenbezogener Daten im Zusammenhang mit KI-Modellen ausdrücklich die Einzelfallprüfung.

Ein deutscher oder europäischer Server kann also ein Baustein einer kontrollierteren Architektur sein. Er ersetzt jedoch keine Bewertung des gesamten Datenflusses.

Welche Fragen sollte man vor der technischen Umsetzung klären?

Bevor ein Modell ausgewählt wird, sollte zuerst der Prozess beschrieben werden.

• Welche konkrete Aufgabe soll die KI übernehmen?
• Welche Daten benötigt sie dafür?
• Welche Daten darf sie nicht sehen?
• Welche Systeme muss sie lesen können?
• Welche Aktionen darf sie selbst ausführen?
• Welche Schritte benötigen eine menschliche Freigabe?
• Welche Teile müssen lokal oder innerhalb einer bestimmten Region laufen?
• Welche Fehler wären akzeptabel und welche nicht?

Erst daraus ergibt sich, welche Modellgröße, Infrastruktur und Integrationen tatsächlich notwendig sind.

Wie ein sinnvoller Prototyp aussehen kann

Ein erster Test sollte nicht direkt den kompletten Geschäftsprozess automatisieren.

Sinnvoller ist eine einzelne Aufgabe, für die reale oder anonymisierte Beispieldaten vorhanden sind. So lässt sich zunächst prüfen, ob das Modell die fachliche Aufgabe zuverlässig genug löst.

Beispieldaten
     |
     v
kleiner abgegrenzter Prozess
     |
     v
Modell + notwendige Datenquelle
     |
     v
messbares Ergebnis

Erst danach werden weitere Datenquellen, Werkzeuge oder automatische Aktionen ergänzt.

Dieser Aufbau trennt mehrere Risiken voneinander. Wenn die Ergebnisse schlecht sind, lässt sich besser feststellen, ob das Modell, die Dokumentensuche oder die Prozesslogik verantwortlich ist.

Wann ist lokale beziehungsweise kontrollierte KI besonders sinnvoll?

Eine eigene oder gezielt kontrollierte Infrastruktur kann interessant sein, wenn ein Modell dauerhaft in interne Prozesse eingebunden wird, sensible Daten verarbeitet werden oder die Kosten eines häufig genutzten externen Dienstes langfristig relevant werden.

Typische technische Einsatzfelder sind interne Wissenssysteme, Dokumentenanalyse, Klassifikation, Datenextraktion, Supportprozesse und KI-Funktionen innerhalb bestehender Software.

Bei Aufgaben, für die sehr große Modelle benötigt werden oder deren Last stark schwankt, kann ein externer Dienst dagegen weiterhin wirtschaftlicher oder technisch einfacher sein.

Lokal und Cloud lassen sich kombinieren

In der Praxis muss die Entscheidung nicht zwischen zwei Extremen fallen.

Ein kleineres selbst betriebenes Modell kann beispielsweise Standardfälle bearbeiten, während ein stärkeres externes Modell nur für besonders komplexe Aufgaben eingesetzt wird.

Anfrage
  |
  v
kleines internes Modell
  |
  +---- Standardfall -> intern lösen
  |
  +---- komplexer Fall
              |
              v
      stärkeres Modell
      oder Mensch

Bei einem solchen hybriden Aufbau muss allerdings genau festgelegt werden, welche Daten an den externen Teil weitergegeben werden dürfen.

Fazit

Lokale KI besteht heute nicht mehr nur aus einem Modell, das auf einem Rechner Texte erzeugt. In realen Anwendungen wird das Sprachmodell mit Datenquellen, Suchsystemen, Sprache und anderen Programmen verbunden.

Gerade bei klar begrenzten Aufgaben kann dadurch ein kleineres Modell ausreichen. RAG liefert aktuelles Wissen von außen, während Fine-Tuning genutzt werden kann, wenn das Verhalten des Modells gezielt angepasst werden soll.

Ob ein System vollständig lokal, auf einem eigenen Server oder teilweise über externe Infrastruktur läuft, ist eine Architekturentscheidung. Entscheidend ist nicht nur der Standort des Modells, sondern der komplette Datenfluss.

Wer lokale KI sinnvoll einsetzen möchte, sollte deshalb nicht mit der Frage nach dem größten Modell beginnen. Die bessere Ausgangsfrage lautet, welche konkrete Aufgabe gelöst werden soll und welche Daten das System dafür tatsächlich benötigt.

Wenn Sie einen konkreten KI-Prozess technisch bewerten oder zunächst als kleinen Prototyp testen möchten, können wir die notwendige Architektur gemeinsam eingrenzen. Zum Erstgespräch.