Wie wir eine lokale KI dauerhaft betreiben und aktualisieren

Das Wichtigste in Kürze

• Eine produktive Fassung umfasst Modell, Einstellungen, Regeln, Datenquellen, Schnittstellen und Oberfläche — nicht nur den Modellnamen.
• Änderungen laufen erst durch Tests und danach durch eine kleine kontrollierte Einführung.
• Beobachtet werden auch Rückstau, Prüfaufwand und Fehlerarten – nicht nur Serverwerte.
• Die vorige stabile Fassung bleibt für einen schnellen Rückweg verfügbar.
• Datensicherung und Ersatzweg werden praktisch geübt, nicht nur dokumentiert.

Eine lokale KI bleibt nicht stabil, nur weil sie das Gebäude nicht verlässt. Betriebssysteme brauchen Sicherheitsupdates. Fachanwendungen ändern Schnittstellen. Kunden schicken neue Dokumentvarianten, gern kurz nachdem sie selbst ihr ERP gewechselt haben. Neue Modelle versprechen bessere Ergebnisse. Die Liste der Störquellen aus unseren Projekten ist unspektakulär — kein einziger Punkt darauf hat mit KI im engeren Sinn zu tun.

Lokaler Betrieb gibt dem Unternehmen Kontrolle über Modelle, Daten und den Zeitpunkt der Änderungen. Diese Kontrolle muss organisiert werden. Von allein organisiert sie sich nicht.

Lokale KI ist kein Gerät im Technikraum. Sie ist ein Geschäftsdienst mit Modell.

Was gemeinsam zu einer Version gehört

Ein Ergebnis hängt von mehr ab als vom Modellnamen. Zu einer produktiven Fassung gehören das Modell samt seiner technischen Ausführung, Software, Treiber und Bibliotheken, der Prompt und die erlaubten Werkzeuge, feste Ausgabefelder und Prüfregeln, Agenten und Geschäftslogik, Wissensquellen mit ihrem Suchstand, die Schnittstellen zu den Fachsystemen, Datenbank und Oberfläche — und darunter Betriebssystem und Hardwareprofil.

Nur dieses vollständige Bündel lässt sich später nachvollziehen oder zuverlässig zurücksetzen. In einem Projekt veränderte ein aktualisierter Treiber messbar die Antworten eines Modells, an dem niemand etwas angefasst hatte. Wer in so einem Fall nur den Modellnamen dokumentiert hat, sucht lange und an der falschen Stelle.

Verantwortung eindeutig festlegen

Eine Person kann mehrere Rollen übernehmen. Im Mittelstand ist das der Normalfall. Die Verantwortung muss trotzdem benannt sein — „das macht die IT“ ist keine Benennung, sondern eine Vertagung.

Ziele in der Sprache des Betriebs festlegen

Ein Server kann erreichbar sein und trotzdem keinen Auftrag abschließen. In einem Projekt meldete das Monitoring über Tage beste Werte — Dienste stabil, Antwortzeiten kurz, die GPU entspannt —, während im Auftragsbüro der älteste Vorgang seit dem Vortag wartete, weil eine Schnittstelle Fälle still ablehnte. Der Server war kerngesund. Der Betrieb nicht.

Darum beobachten wir Werte, die der Fachbereich versteht: das Alter des ältesten wartenden Vorgangs, die Zahl der bearbeiteten Vorgänge pro Stunde oder Tag, die Zeit vom Eingang bis zum Ergebnis, technische Fehler, den Anteil der Fälle mit menschlicher Prüfung, neue oder häufiger werdende Fehlerarten und die Zeit bis zum Wiederanlauf nach einem Ausfall. GPU-Auslastung bleibt interessant. Sie beantwortet nur selten die Frage, ob die Auftragsbearbeitung funktioniert.

Vier Ebenen beobachten

Erst die Verbindung dieser Ebenen zeigt, ob ein technisches Problem den Betrieb trifft oder ob die Qualität schleichend sinkt. Schleichend ist dabei das entscheidende Wort: Ein Ausfall meldet sich von selbst, eine langsam wachsende Korrekturquote nicht.

Änderungen nach ihrer Wirkung behandeln

Ein lehrreicher Zwischenfall aus einem unserer Projekte kam nicht vom Modell, sondern von einer Fachanwendung: Nach einem nächtlichen Update lieferte sie Datumsangaben in anderem Format. Die KI tat das einzig Richtige und stoppte jeden betroffenen Vorgang — am Morgen stand der Rückstau in der Oberfläche, samt Grund. Der feste Testsatz hätte den Fehler vorab gezeigt. Seitdem läuft er auch bei Änderungen, die mit der KI scheinbar nichts zu tun haben.

Neue Fassungen stufenweise einführen

Eine neue Fassung durchläuft vier Stufen. Zuerst der Test auf dem festen Datensatz, ohne jede Außenwirkung. Dann ein Schattenlauf: Die neue Fassung bearbeitet dieselben Vorgänge wie die laufende, aber nur zum Vergleich — ihre Ergebnisse erreichen niemanden. In einem Projekt fiel dabei auf, dass ein neuer Modellkandidat spürbar schönere Auftragsbestätigungen schrieb und nebenbei ein Mengenformat veränderte, mit dem die Warenwirtschaft nichts anfangen konnte. Genau dafür ist der Schattenlauf da.

Danach übernimmt die neue Fassung eine kleine Gruppe begrenzter Vorgänge unter enger Beobachtung, und erst wenn die Messwerte stabil sind, den Betrieb. Zwischen den Stufen stehen klare Grenzen. Eine neue Fassung wird nicht nur deshalb weitergeschoben, weil ein paar Tage lang nichts auffiel. Qualität, Zeit und Fehlerweg müssen passen.

Den Rückweg vor der Änderung vorbereiten

Die vorige stabile Fassung bleibt vollständig verfügbar. Datenbankänderungen werden so geplant, dass alte und neue Software vorübergehend zusammenarbeiten können oder ein getesteter Rückweg besteht.

Offene Vorgänge dürfen beim Wechsel nicht verloren gehen. Außerdem ist festgelegt, wer die Rückkehr auslöst. Ein Rückweg, über den erst im Fehlerfall diskutiert wird, ist noch keiner.

Kapazität und Lebensdauer planen

Lokale Hardware wird nicht nur nach dem Durchschnitt ausgelegt. Wichtig sind Spitzen, gleichzeitige Nutzer, Seitenzahl, längere Dokumente und weitere geplante Anwendungen — die erfahrungsgemäß schneller angefragt werden, als die erste Anwendung ausgereift ist.

Zum Lebenszyklus gehört mehr: Reserve für Wachstum und Störungen, ein Ersatzgerät oder ein vertraglich geregelter Tausch, Garantie und Lieferzeit, das Ende des Treiber- und Software-Supports, die spätere Migration auf andere Modelle und am Ende die sichere Außerbetriebnahme samt Löschung der Datenträger. Nichts davon ist aufregend. Vergessen wird es trotzdem regelmäßig.

Wiederherstellung praktisch üben

Gesichert werden Datenbank, Konfiguration, Modelle, Testsatz, Zertifikate und notwendige Zugangsdaten. Und dann wird die Sicherung tatsächlich eingespielt — auf einer sauberen Umgebung, mit einem vollständigen Testvorgang hinterher. In einem Projekt lief die Sicherung monatelang jede Nacht fehlerfrei durch; beim ersten Probelauf fehlte das Zertifikat für die Anbindung der Warenwirtschaft, das nie Teil der Sicherung gewesen war.

Erst der geübte Wiederanlauf belegt, dass die Plattform zurückkommen kann. Ein grünes Sicherungsprotokoll belegt nur, dass ein Protokoll geschrieben wurde.

Das monatliche Betriebsreview

Ein kurzer gemeinsamer Termin von Fachbereich und IT genügt. Auf den Tisch kommen Fallmenge und erreichte Entlastung, Prüf- und Ausnahmerate, neue Fehler und die Zeit bis zur Korrektur, Rückstau und technische Störungen, Sicherheitsereignisse und geänderte Rechte, anstehende Updates sowie neue Prozess- oder Schulungsbedarfe.

So bleibt die Lösung ein gemeinsames Produkt. Sonst wird sie schnell zu einem unsichtbaren Server, an den sich alle nur bei Problemen erinnern.

Betriebscheckliste

• Ist die vollständige produktive Fassung nachvollziehbar dokumentiert?
• Sind fachliche und technische Verantwortungen benannt?
• Werden Rückstau, Prüfaufwand und Qualität beobachtet?
• Laufen Änderungen durch Test und kleine Einführung?
• Ist die vorige stabile Fassung sofort verfügbar?
• Passen Ersatzweg und Wiederherstellungszeit zum Betrieb?
• Werden größere Umfangsänderungen neu geprüft?

Fazit

Lokale KI bleibt beherrschbar, wenn sie wie ein wichtiger Geschäftsdienst betrieben wird — mit klarer Verantwortung, vollständigen Versionen, brauchbaren Messwerten, kontrollierten Änderungen und geübter Wiederherstellung.

Das ist unspektakuläre Arbeit, und genau deshalb funktioniert sie. Qualität und Souveränität bleiben so auch nach dem ersten erfolgreichen Jahr erhalten.

Quellen und weiterführende Hinweise

1. NIST: AI Risk Management Framework
2. NIST: Notfall- und Wiederanlaufplanung
3. OWASP: Sicherheitsprinzipien für KI-Agenten
4. Europäische Kommission: Überblick zum EU AI Act

Der Betrieb beginnt vor der Einführung

Verantwortung, Messwerte, Rückweg und Wiederherstellung gehören bereits in die Architektur.

Betriebsmodell besprechen