Lokaler Betrieb einer KI: Architektur, Datenschutz und Kosten für Unternehmen

Der lokale Betrieb einer KI – auch On-Premises-KI oder selbst gehostete KI genannt – verlagert die Ausführung eines Modells in eine Infrastruktur, die das Unternehmen selbst betreibt oder kontrolliert. Bei einem lokalen Sprachassistenten gehen Anfragen zunächst an einen internen Inferenzserver statt an eine öffentliche Modell-API. Das Modell erzeugt dort seine Antwort. Ob dabei tatsächlich alle Daten intern bleiben, hängt von der gesamten Anwendung ab: Chat-Oberfläche, Dokumentenverarbeitung, Anmeldung, Protokollierung und zusätzliche Werkzeuge gehören zur Betrachtung.

Für IT-Leiter:innen im Mittelstand ist die Kernfrage deshalb nicht „Welches Modell lässt sich installieren?“, sondern: Welchen geschäftlichen Vorgang soll die KI unterstützen, welche Daten darf sie sehen und wie wird ihre Leistung überprüft? Ein lokaler Chatbot für interne Wissensdokumente stellt andere Anforderungen als ein Assistent, der Tickets klassifiziert oder Code aus einem Repository analysiert.

Zuletzt aktualisiert: 30. September 2026

Was bedeutet lokaler Betrieb einer KI?

Eine KI wird lokal betrieben, wenn ihre Inferenz – also das Verarbeiten einer Eingabe und Erzeugen einer Ausgabe – auf dafür bereitgestellter Infrastruktur des Unternehmens stattfindet. Das kann ein einzelner Arbeitsplatzrechner, ein GPU-Server im eigenen Rechenzentrum oder ein intern verwalteter Cluster sein. „Lokal“ beschreibt zunächst den Ausführungsort. Es sagt noch nichts darüber aus, wie das Modell heruntergeladen wurde, wohin Protokolle fließen oder ob ein eingebundenes Zusatzwerkzeug einen Cloud-Dienst nutzt.

Drei Betriebsbegriffe sollten getrennt werden:

Ein lokal gestarteter Chat beweist beispielsweise nicht, dass auch die Dokumentensuche lokal ist. Für eine vollständig offline nutzbare RAG-Anwendung müssen unter anderem Dokumentenextraktion, Embedding-Modell und gegebenenfalls Reranker lokal verfügbar sein. Offline-Einstellungen allein blockieren ausgehende Verbindungen nicht; dafür sind zusätzliche Netzwerkkontrollen nötig.

Wann lohnt sich lokale KI für Unternehmen?

Lokale KI ist prüfenswert, wenn eine Organisation Anfragen mit vertraulichen Unterlagen bearbeiten möchte, externe Datenflüsse begrenzen muss oder eine verlässlich erreichbare Anwendung im internen Netz benötigt. Typische Pilotfälle sind die Suche in freigegebenen IT-Handbüchern, die Zusammenfassung interner Störungsberichte oder die Unterstützung beim Formulieren technischer Dokumentation. Der Nutzen hängt davon ab, ob Antworten korrekt, schnell genug und für die zuständigen Personen tatsächlich hilfreich sind.

Ein weiterer Grund kann die Kontrolle über das Betriebsmodell sein. Das Unternehmen bestimmt, wann ein Modell aktualisiert wird, welche Anwendung es aufrufen darf und wie Zugriffe protokolliert werden. Diese Kontrolle bringt Verantwortung mit sich: GPU-Kapazität, Patches, Sicherungen und Störungsbehebung verschwinden nicht, sondern werden Teil des eigenen IT-Betriebs.

Die Tabelle ist keine pauschale Kosten- oder Qualitätswertung. Ein externer Dienst kann bei schwankender Nutzung wirtschaftlicher sein; ein lokaler Betrieb kann bei klaren Datenanforderungen oder planbarer Auslastung Vorteile bieten. Beides muss am konkreten Workload geprüft werden.

Welche Komponenten braucht eine lokale KI?

Eine produktive Lösung besteht nicht nur aus einer Modelldatei. Sie verbindet mehrere Schichten, für die häufig unterschiedliche Teams verantwortlich sind:

1. Modell: Die Gewichte und zugehörigen Dateien bestimmen unter anderem unterstützte Aufgaben, Sprachen, Kontext und Nutzungsrechte.
2. Inferenzserver: Er lädt das Modell und stellt es über eine Schnittstelle für Anwendungen bereit.
3. Benutzeroberfläche oder Fachanwendung: Sie nimmt Eingaben entgegen, zeigt Antworten an und steuert den Arbeitsablauf.
4. Identitäts- und Rechteverwaltung: Sie begrenzt, wer welche Funktionen und Daten nutzen darf.
5. Optionaler Dokumentenzugriff: Extraktion, Segmentierung, Embeddings, Suche und gegebenenfalls Reranking stellen relevante Inhalte bereit.
6. Betriebsdienste: Monitoring, Protokollierung, Backup, Aktualisierung und Netzwerkschutz halten die Lösung beherrschbar.

Ollama kann beispielsweise Modelle lokal über eine API bereitstellen. Open WebUI ist eine mögliche selbst gehostete Benutzeroberfläche, die lokale und externe Modell-Endpunkte anbinden kann. vLLM eignet sich als Inferenzserver unter anderem für anspruchsvollere Bereitstellung und die Verteilung eines Modells über mehrere GPUs. Diese Werkzeuge erfüllen unterschiedliche Aufgaben; die Kombination entscheidet über den tatsächlichen Datenfluss.

Eine nachvollziehbare Architekturzeichnung sollte deshalb jeden Weg zeigen: Browser → Oberfläche → Modellserver sowie – falls eingesetzt – Oberfläche → Dokumentenverarbeitung → Suche → Modellserver. Für jede Verbindung ist zu klären, welche Inhalte übertragen werden und ob sie das interne Netz verlassen können.

Welche Hardware benötigt eine lokale KI?

Die Hardware richtet sich nach Modellgröße, gewünschter Antwortgeschwindigkeit, Kontextlänge und gleichzeitigen Anfragen. Ein kleines Pilotmodell auf einem Arbeitsplatz stellt andere Anforderungen als ein unternehmensweiter Assistent mit langen Dokumenten und vielen parallelen Nutzenden. Besonders wichtig ist der verfügbare GPU-Speicher: Neben den Modellgewichten benötigt die Inferenz Speicher für den Kontext und gleichzeitig laufende Anfragen.

Quantisierung kann den Speicherbedarf eines Modells verringern, indem Gewichte mit geringerer Genauigkeit gespeichert werden. Der mögliche Gewinn hängt vom gewählten Modell und Verfahren ab; die Antwortqualität muss für den vorgesehenen Zweck getestet werden. Wird ein Modell zwischen GPU und Arbeitsspeicher aufgeteilt oder vollständig auf einer CPU ausgeführt, ist das prinzipiell möglich, kann aber die Reaktionszeit beeinflussen. Bei mehreren GPUs kommen Verfahren wie Tensor- oder Pipeline-Parallelismus infrage. vLLM beschreibt beispielsweise eine einzelne GPU als naheliegend, wenn das Modell vollständig hineinpasst; erst bei größeren Modellen wird die Verteilung relevant.

Für die Beschaffung zählen gemessene statt angenommene Werte:

• Wie lange dauert es bis zum ersten sichtbaren Antwortteil?
• Wie schnell wird eine typische vollständige Antwort erzeugt?
• Wie viele Personen können gleichzeitig arbeiten?
• Wie groß sind die tatsächlich benötigten Eingaben und Dokumentauszüge?
• Wie verändern längere Kontexte und parallele Anfragen den Speicherbedarf?

Ollama weist ausdrücklich darauf hin, dass parallele Verarbeitung zusätzlichen Speicher für den Kontext benötigt. Ein Test mit einer einzelnen kurzen Frage reicht deshalb nicht als Grundlage für einen Mehrbenutzerbetrieb.

Wie wählt man ein lokales KI-Modell aus?

Das geeignete Modell ist nicht zwingend das größte. Für einen internen Wissensassistenten sind etwa deutschsprachige Antwortqualität, Befolgung von Anweisungen, Umgang mit Fachbegriffen, Kontextbedarf und Antwortgeschwindigkeit wichtig. Für Codeanalyse kommen andere Testaufgaben hinzu. Die Auswahl sollte mit einem festgelegten Satz realistischer, erlaubter Unternehmensfragen erfolgen – einschließlich Fragen, auf die das System ausdrücklich nicht antworten darf.

Vor der Installation sind außerdem Modellkarte und Lizenzbedingungen zu prüfen. Eine offen zugängliche Modelldatei ist nicht automatisch uneingeschränkt für jeden kommerziellen Einsatz freigegeben. Modellkarten können Angaben zu Lizenz, vorgesehenen Anwendungen und Grenzen enthalten; einzelne Modelle erfordern zusätzlich eine Zugangsfreigabe. Diese Prüfung gehört in den Beschaffungs- und Freigabeprozess.

Unternehmen sollten für jedes freigegebene Modell Version, Bezugsquelle, Lizenzbewertung, technische Einstellungen und Ergebnisse der Qualitätstests dokumentieren. Sonst ist später kaum nachvollziehbar, ob eine veränderte Antwort vom Modellwechsel, einer neuen Dokumentenbasis oder geänderten Anwendungseinstellungen stammt.

Wie nutzt lokale KI interne Dokumente?

Ein Sprachmodell kennt neue interne Handbücher nicht automatisch. Für Fragen zu aktuellen Unternehmensunterlagen wird häufig Retrieval-Augmented Generation, kurz RAG, eingesetzt. Die Anwendung extrahiert Text aus freigegebenen Dokumenten, teilt ihn in sinnvolle Abschnitte und macht diese über eine Suche auffindbar. Bei einer Frage erhält das Modell passende Auszüge als Kontext und formuliert daraus eine Antwort.

RAG trainiert das Sprachmodell dabei nicht automatisch neu. Es stellt Inhalte für eine konkrete Anfrage bereit. Das erleichtert die Aktualisierung der Wissensbasis, verschiebt aber einen Teil der Qualitätsfrage auf Dokumente und Suche: Sind die Unterlagen aktuell? Werden die richtigen Abschnitte gefunden? Kann die anfragende Person diese Dokumente überhaupt sehen?

Ein Beispiel ist ein interner Assistent für Betriebsanleitungen. Fragt ein Administrator nach dem freigegebenen Verfahren zur Wiederherstellung eines Servers, sollte die Anwendung nur Dokumente aus dem für ihn berechtigten Bereich durchsuchen. Die Antwort sollte die verwendete Dokumentversion erkennen lassen und bei fehlenden Angaben offen sagen, dass keine belastbare Anweisung gefunden wurde. Ein plausibel formulierter, aber nicht belegter Wiederherstellungsschritt darf nicht als freigegebener Betriebsprozess erscheinen.

Für einen durchgängig lokalen Betrieb müssen auch Embedding-Modell, Dokumentenextraktion und optionaler Reranker lokal laufen. Ein lokales Chatmodell neben einer externen Embedding-API wäre keine vollständig lokale Dokumentenverarbeitung.

Ist eine lokale KI automatisch datenschutzkonform?

Nein. Der lokale Ausführungsort kann bestimmte Datenübermittlungen vermeiden, beseitigt aber nicht die Anforderungen an die Verarbeitung personenbezogener Daten. Prompts, hochgeladene Unterlagen, Antworten, Benutzerkennungen und Protokolle können personenbezogene Informationen enthalten. Auch das verwendete Modell selbst kann datenschutzrechtliche Fragen aufwerfen. Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit betont in ihrer Handreichung vom Dezember 2025, dass ein Modell auf eigener Infrastruktur keine Ausnahme von den üblichen Verantwortlichkeiten schafft.

Für ein Unternehmen sind vor allem folgende Fragen zu klären:

• Zu welchem konkreten Zweck werden Eingaben und Dokumente verarbeitet?
• Welche Beschäftigten- oder Kundendaten dürfen in der Anwendung vorkommen?
• Auf welcher Grundlage erfolgt die Verarbeitung?
• Wer kann Eingaben, Antworten, Protokolle und gespeicherte Unterhaltungen sehen?
• Wie lange bleiben diese Daten gespeichert, und wie werden sie gelöscht?
• Sind eine Datenschutz-Folgenabschätzung oder weitere Prüfungen erforderlich?

Besonders sensible Daten benötigen eine gesonderte Bewertung. „Die Daten verlassen das Haus nicht“ ist dafür keine ausreichende Begründung. Ebenso darf ein lokal gehostetes Modell nicht ohne Prüfung mit umfangreichen internen Dokumenten nachtrainiert werden. Ob Retrieval, Fine-Tuning oder eine andere Verarbeitung zulässig und geeignet ist, hängt von Zweck und Daten ab.

Was verlangt der EU AI Act beim lokalen Betrieb?

Der EU AI Act gilt nicht nur für Cloud-KI. Entscheidend sind unter anderem die Rolle einer Organisation und der konkrete Einsatz des KI-Systems, nicht allein der Standort des Servers. Nach der veröffentlichten Umsetzungslinie gelten Bestimmungen zur KI-Kompetenz seit dem 2. Februar 2025; Transparenzpflichten nach Artikel 50 gelten seit dem 2. August 2026. Weitere Pflichten greifen je nach Systemtyp und Zeitpunkt gestaffelt.

Für eine interne Wissenssuche, einen Kundenchatbot und eine KI-gestützte Personalentscheidung können deshalb unterschiedliche Anforderungen relevant sein. Die genaue rechtliche Einordnung sollte vor dem Produktivbetrieb erfolgen. Der lokale Betrieb ist weder eine pauschale Ausnahme von der KI-Verordnung noch ein Beleg dafür, dass die Anwendung unter eine bestimmte Risikokategorie fällt. Der AI Act und die DSGVO sind zudem getrennt zu prüfen.

Wie schützt man eine lokale KI?

Eine lokal installierte KI ist ein zusätzliches IT-System mit Zugriffswegen, Abhängigkeiten und potenziell sensiblen Daten. Besondere Aufmerksamkeit verdient die API des Inferenzservers. Ollama bindet standardmäßig an 127.0.0.1:11434; seine lokale API verlangt nach der Produktdokumentation keine Authentifizierung. Wer sie für andere Geräte erreichbar macht, muss den Zugang deshalb vorab über Netzwerk, vorgeschaltete Authentifizierung und geeignete Transportabsicherung schützen. Sie sollte nicht unvermittelt für das Unternehmensnetz oder Internet geöffnet werden.

Ebenso wichtig sind Berechtigungen innerhalb der Anwendung. Ein RAG-System darf vertrauliche Dokumente nicht allein deshalb zurückgeben, weil sie technisch im selben Suchindex liegen. Die Berechtigungsprüfung muss außerhalb des Sprachmodells durchgesetzt werden. Zugangsdaten gehören nicht in Systemprompts; Werkzeuge, die Dateien ändern oder Nachrichten versenden können, benötigen eng begrenzte Rechte und für kritische Aktionen eine Freigabe.

Ein weiteres Risiko ist Prompt Injection: Ein manipuliertes Dokument kann Text enthalten, der den Assistenten zu einem unerwünschten Verhalten auffordert. Externe und intern veränderbare Dokumente sollten als Daten behandelt werden, nicht als vertrauenswürdige Anweisungen. Tests mit absichtlich präparierten Inhalten gehören deshalb zur Freigabe.

Was kostet der lokale Betrieb einer KI?

Eine seriöse Kostenschätzung umfasst mehr als den Kauf eines GPU-Servers. Hardware und Strom sind sichtbar; häufig unterschätzt werden Integration, Betrieb, Qualitätsprüfung und laufende Aktualisierungen. Für den Vergleich mit einem externen Dienst sollte ein Unternehmen dieselbe Aufgabe und denselben Zeitraum zugrunde legen.

Ein Pilot sollte Kosten und Nutzen pro relevantem Vorgang erfassen: etwa Zeitersparnis bei der Suche in freigegebenen Handbüchern und Aufwand für die Überprüfung der Antworten. Eine hohe Zahl generierter Texte allein ist kein Geschäftsnutzen. Genauso wenig beweist ein niedriger Preis pro Anfrage, dass eine Lösung für sensible Daten geeignet ist.

Wie führt man lokale KI ein?

1. Anwendungsfall eingrenzen. Wählen Sie eine wiederkehrende Aufgabe mit klaren Eingaben, erlaubten Daten und überprüfbarem Ergebnis.
2. Schutzbedarf feststellen. Klassifizieren Sie Dokumente, Prompts und Ausgaben; beziehen Sie Datenschutz und Informationssicherheit früh ein.
3. Betriebsmodell zeichnen. Erfassen Sie alle Komponenten und Datenflüsse – auch Anmeldung, Embeddings, Suchindex, Protokolle und Updates.
4. Modell und Hardware testen. Vergleichen Sie mehrere zulässige Modelle mit realistischen Fragen und paralleler Last.
5. Zugriffe begrenzen. Sichern Sie APIs ab und setzen Sie Dokumentenrechte technisch durch.
6. Qualität messen. Bewerten Sie korrekte Antworten, unbelegte Aussagen, Verweigerung bei fehlender Grundlage und Bedienbarkeit.
7. Ausfälle und Angriffe erproben. Testen Sie unter anderem fehlende Dokumente, überlastete GPUs, manipulierte Inhalte und Wiederherstellung.
8. Pilot begrenzt freigeben. Erst nach fachlicher, technischer und rechtlicher Prüfung folgt eine Erweiterung auf weitere Teams.

Gerade bei einer internen Wissenssuche ist der sechste Schritt entscheidend: Ein Assistent, der schnell antwortet, aber veraltete Anleitungen überzeugend präsentiert, verschlechtert unter Umständen den Betrieb. Er sollte deshalb zwischen gefundenem Wissen und einer bloßen Vermutung unterscheiden.

Bleiben bei Ollama alle Daten automatisch im Unternehmen?

Bei der Nutzung lokaler Modelle verarbeitet Ollama die Anfragen lokal. Das sagt jedoch noch nichts über eine vorgeschaltete Oberfläche oder angebundene Dienste aus. Ollama bietet auch Cloud-Funktionen; für einen ausdrücklich lokalen Modus lassen sie sich deaktivieren. Zudem ist die lokale API standardmäßig ohne eigene Authentifizierung erreichbar – zunächst nur über die Loopback-Adresse. Wird sie im Netz freigegeben, sind zusätzliche Zugriffskontrollen nötig. Ein Unternehmen sollte daher die gesamte Anwendung und nicht nur den Modellserver auf Datenflüsse prüfen.

Was passiert, wenn das lokale Modell eine falsche Antwort gibt?

Der Ausführungsort ändert nichts daran, dass ein Sprachmodell unbelegte oder falsche Aussagen erzeugen kann. Ein Unternehmensassistent sollte wichtige Antworten anhand freigegebener Unterlagen überprüfbar machen und Unsicherheit erkennen lassen. Für Entscheidungen mit erheblichen Folgen sind fachliche Kontrolle und klare Freigabeprozesse nötig. Bei einer Betriebsanleitung bedeutet das: Die KI kann bei der Suche und Zusammenfassung helfen, eine ungeprüfte Antwort sollte aber keinen verbindlichen Wiederherstellungsprozess ersetzen. Qualitätsmessung muss auch Fälle enthalten, in denen die richtige Reaktion „keine ausreichende Grundlage gefunden“ lautet.

Was ist der Unterschied zwischen RAG und Fine-Tuning?

RAG sucht zur Anfrage passende Inhalte und gibt sie dem Modell für diese Antwort als Kontext. Die Modellgewichte ändern sich dadurch nicht. Fine-Tuning passt dagegen ein Modell durch zusätzliches Training an. Für eine häufig aktualisierte interne Wissensbasis ist RAG oft der naheliegende erste Prüfpfad, weil Dokumente ohne erneutes Modelltraining ausgetauscht werden können. Es garantiert aber keine korrekten Antworten: Dokumentqualität, Trefferwahl und Berechtigungen bleiben kritisch. Fine-Tuning kann für andere Ziele sinnvoll sein und erfordert eine gesonderte Prüfung von Trainingsdaten, Rechten und Qualität.

Ist lokale KI sicherer als ein externer KI-Dienst?

Nicht automatisch. Ein lokaler Betrieb kann externe Datenübertragungen begrenzen und dem Unternehmen mehr technische Kontrolle geben. Gleichzeitig muss es APIs absichern, Modelle und Software aktualisieren, Berechtigungen prüfen und Angriffe auf angebundene Dokumente berücksichtigen. Ein externer Dienst hat andere Risiken und Verantwortlichkeiten. Sicherheit lässt sich daher nicht aus dem Standort allein ableiten. Aussagekräftig ist eine dokumentierte Bewertung der konkreten Datenflüsse, Bedrohungen und Schutzmaßnahmen beider Optionen.

Braucht eine lokale KI zwingend eine GPU?

Nein. Eine CPU kann ein Modell grundsätzlich ausführen. Ob die Antwortzeit für Beschäftigte akzeptabel ist, hängt jedoch von Modellgröße, Quantisierung, Kontext und Zahl paralleler Anfragen ab. Eine GPU kann Inferenz beschleunigen, bringt aber Kosten und zusätzliche Betriebsanforderungen mit sich. Statt eine feste Hardwaregröße aus einer allgemeinen Empfehlung abzuleiten, sollte das Team die ausgewählten Modelle mit typischen Aufgaben testen. Besonders lange Dokumentkontexte und gleichzeitige Anfragen können den Speicherbedarf deutlich erhöhen.

Welche Weiterbildung passt zum Thema?

Für die fachliche Einführung bieten die Seiten von allskills-training.com „Grundlagen KI & Hands-On GPT“ und „ChatGPT: Prompt Engineering und Grundlagen“. Für Teams, die KI in Entwicklungsabläufe integrieren, ist „Generative KI in der Softwareentwicklung“ thematisch passend. Wer eine lokale Virtualisierungsplattform betreibt, kann die Infrastrukturkenntnisse im Seminar „Proxmox VE 9 Installation und Verwaltung“ vertiefen. Diese Kurse sind angrenzende Qualifizierungsangebote und nicht ohne Weiteres als spezialisierte Schulung für den Betrieb eines bestimmten lokalen KI-Modells zu verstehen. allskills Training Berlin bietet laut Kursseiten entsprechende Schulungsformate an.