Ihr KI-Pilot ist so nützlich, dass eine Abteilung darauf angewiesen sein möchte. Nun ändern sich die Fragen. Wo werden Dokumente gespeichert? Was geschieht beim Ausfall des Modelldienstes? Wer installiert Updates, stellt einen Index wieder her oder prüft die Antworten eines neuen Modells? Diese Infrastruktur- und Administrationsentscheidungen brauchen Verantwortliche vor dem Start.
Für ein luxemburgisches Unternehmen bedeutet die Bereitstellung von KI-Infrastruktur, die Umgebung um den Workload aufzubauen. KI-Systemadministration hält diese Umgebung und ihre Integrationen nach der Übergabe zuverlässig. Diese Checkliste begleitet einen beispielhaften internen Wissensassistenten von der Architektur bis zum Betrieb; dieselben Fragen gelten für viele Kundenservice- und Agentenabläufe.
Beginnen Sie mit dem Workload und seinen Betriebsanforderungen
Dokumentieren Sie Aufgabe, Nutzer, unterstützte Sprachen, Datenklassifikation und erlaubte Aktionen. Entscheiden Sie, ob eine verzögerte Antwort lästig oder geschäftskritisch ist. Benennen Sie Personen für Änderungsfreigaben und Vorfallmeldungen. Ein Modellbenchmark kann Ihnen diese Entscheidungen nicht abnehmen.
Definieren Sie die vollständige Abhängigkeitskette: Identitätsanbieter, Anwendung, Modell-Endpunkt, Dokumentaufnahme, Embedding-Dienst, Vektordatenbank, Agenten-Harness, MCP-Server und nachgelagerte APIs. Kennzeichnen Sie eigene und lieferantenabhängige Komponenten. Berücksichtigen Sie DNS, Zertifikate, Speicher und Backup-Dienste im Diagramm.
Unser Service zur Bereitstellung von KI-Infrastruktur beginnt mit diesen Anforderungen, damit die Umgebung zum vorgesehenen Zweck passt. Legen Sie akzeptable Antwortzeiten, Wiederherstellungsziele und Budgetgrenzen vor dem Hostingvergleich fest. Sonst kann aus einer attraktiven Vorführung eine ungeeignete Produktionsarchitektur entstehen.
Benennen Sie für den beispielhaften Wissensassistenten einen Dokumentverantwortlichen vor der Speicherwahl. Diese Person legt verbindliche Quellen, erlaubte Leser und Löschzeitpunkte fest. Ein Administrator kann die Regeln umsetzen, sollte sie aber nicht aus Ordnernamen ableiten müssen. Dokumentieren Sie den Unterschied zwischen Plattformverantwortung und Verantwortung für die Informationen, die die Plattform zugänglich macht.
Wählen Sie Hosting anhand des vollständigen Datenflusses
On-Premises-, europäische Cloud- und Hybridarchitekturen bringen unterschiedliche Betriebsverantwortung mit sich. Lokalisieren Sie Modell, Dokumentquellen, Embeddings, Protokolle, Backups und Supportzugriffe. Eine europäisch gehostete Anwendung kann weiterhin Prompts an ein Modell andernorts senden oder Telemetrie zu einem anderen Anbieter übertragen.
| Option | Zu treffende Entscheidungen | Zu bestätigende Verantwortung |
|---|
| On-Premises | Hardware, Strom, Kapazität und physischer Zugang | Patches, Ersatzgeräte, Backups und Wiederherstellung |
| Europäische Cloud | Region, Dienstgrenzen und Anbieterzugriff | Cloud-Berechtigungen, Verbrauchsgrenzen und geteilter Betrieb |
| Hybrid | Daten und Anfragen, die Grenzen überschreiten dürfen | Verbindung, Ausfallverhalten und aufgeteilte Vorfallverantwortung |
Dokumentieren Sie Aufbewahrungs- und Löschregeln für jeden Speicher einschließlich abgeleiteter Indizes. Prüfen Sie Modelllizenzen, Auftragsverarbeitung und Supportzugriffe anhand des Anwendungsfalls. Der Hostingstandort ist ein Entscheidungskriterium, begründet aber allein weder Datenschutz noch regulatorische Konformität.
Halten Sie einen praktischen Wechselplan bereit. Erfassen Sie übertragbare Konfigurationen, Dokumente und Anwendungskomponenten sowie Voraussetzungen zum Neuaufbau eines Index. Portabilität lässt sich leichter prüfen, bevor eine anbieterspezifische Funktion zur versteckten Abhängigkeit sämtlicher Abläufe wird.
Dimensionieren Sie den Modellbetrieb mit repräsentativen Anfragen
Kapazität hängt von Modell, Laufzeit, Präzision, Kontextlänge, Antwortlänge und gleichzeitiger Nutzung ab. Prüfen Sie den vollständigen Anfrageweg mit repräsentativen Dokumenten, statt eine GPU nur anhand des Modellnamens auszuwählen. Ein Assistent für lange Verträge hat andere Anforderungen als ein Supportbot mit kurzen Antworten.
Messen Sie Wartezeit bis zum Antwortbeginn, Gesamtdauer, Anfragewarteschlange und Verhalten bei Lastspitzen. Berücksichtigen Sie Indexierung und Hintergrundaufgaben. Definieren Sie das Verhalten bei ausgelastetem Dienst: begrenzte Warteschlange, verständliche Fehlermeldung, Ersatzweg oder Übergabe an einen Menschen.
Wenn Kubernetes geeignet ist, erläutert die Dokumentation zur GPU-Zuteilung die Bereitstellung von Beschleunigerressourcen durch Geräte-Plugins. Die Orchestrierung sollte zum Workload und zur Betriebsfähigkeit Ihres Teams passen; kleinere Bereitstellungen können eine einfachere Plattform benötigen.
Validieren Sie die genaue Laufzeit- und Modellkonfiguration für die Freigabe. Quantisierung oder längere Kontexte können Qualität und Ressourcenverbrauch verändern. Bewahren Sie Kapazitätsmessungen mit Evaluierungsergebnissen auf, damit eine Leistungsänderung den Standard für Nutzer nicht unbemerkt verschiebt.
Trennen Sie Identitäten, Werkzeuge und Netzwerkzugriff
Geben Sie Nutzern und Diensten die notwendigen Rechte für eine benannte Aufgabe. Trennen Sie Verwaltungsoberflächen von gewöhnlichen Inferenz-Endpunkten. Verwalten Sie Geheimnisse außerhalb von Prompts und Quelldokumenten und benennen Sie Verantwortliche für die Rotation. Ein gemeinsam genutztes Administratortoken erschwert Untersuchung und Zugriffsprüfung.
Für den beispielhaften Wissensassistenten sollten Dokumentsuche und E-Mail-Versand getrennte Berechtigungen haben. Retrieval muss die Rechte des anfragenden Nutzers beachten. Ein Agent darf kein Schreibrecht erhalten, nur weil eine andere Anwendungskomponente darüber verfügt. Erzwingen Sie Freigaben sensibler Aktionen im Ausführungspfad.
Erfassen Sie MCP-Clients, Server, Transporte und vorgelagerte Dienste. Prüfen Sie die offiziellen MCP-Sicherheitshinweise für den eingesetzten Autorisierungsablauf. Behandeln Sie Installation, Konfigurationsänderungen und neue Werkzeugzugriffe als gesteuerte Änderungen mit dokumentierter Freigabe.
Beschränken Sie ausgehende Ziele, soweit der Workload dies erlaubt. Modelldienst, Dokumentaufnahme und Verwaltungsoberfläche benötigen möglicherweise unterschiedliche Netzwerkrechte. Prüfen Sie diese Grenzen und nach einer Migration oder einem Connector-Update erneut, da sich übernommene Berechtigungen verändern können.
Überwachen Sie Dienstzustand und Antwortqualität
Ein laufender Prozess ist kein Beweis für einen funktionierenden KI-Dienst. Prüfen Sie, ob Anfragen das Modell erreichen, erlaubte Dokumente abgerufen und Antworten zurückgegeben werden. Trennen Sie Verfügbarkeitstests von repräsentativen Qualitätsbewertungen. Erstere können bestehen, während Letztere defektes Retrieval oder veränderte Modellantworten zeigen.
Die vLLM-Dokumentation zu Produktionsmetriken umfasst Warteschlangenzeit, Gesamtlatenz und Zeit bis zum ersten Token. Verwenden Sie unterstützte Metriken Ihres Serving-Stacks, um Verzögerungen zu erklären, statt ausschließlich durchschnittliche Antwortzeiten zu beobachten.
Wählen Sie Alarme mit konkreter Reaktion. Benennen Sie Empfänger, Prüfschritte und Eskalationszeitpunkt. Beobachten Sie Anfragefehler, Ressourcensättigung, ungewöhnliche Werkzeugaktionen und auffälligen Verbrauch. Halten Sie Protokolle für Untersuchungen nutzbar und kontrollieren Sie Zugriff und Aufbewahrung; Prompts und abgerufene Inhalte können sensibel sein.
Die Prometheus-Instrumentierungshinweise empfehlen dienstbezogene Metriken und kontrollierte Label-Kardinalität. Verwenden Sie deshalb keine beliebigen Nutzerprompts oder Dokumentkennungen als Metriklabels. Prüfen Sie Telemetrie als eigenständigen Datenfluss mit eigener Exposition und eigenen Betriebskosten.
Belegen Sie die Wiederherstellung vor Abschluss der Bereitstellung
Listen Sie auf, was erhalten bleiben muss und was neu aufgebaut werden kann: Quelldokumente, Berechtigungen, Anwendungskonfiguration, Prompts, Evaluierungsdaten, Indizes und Bereitstellungsmanifeste. Ein Backup des Vektorindex allein erhält möglicherweise weder Quellenverantwortung noch Zugriffsregeln für eine sichere Nutzung.
Stellen Sie in einer isolierten Umgebung wieder her und führen Sie repräsentative Prüfungen durch. Bestätigen Sie weiterhin eingeschränkten Dokumentzugriff und unveränderte Werkzeugrechte. Messen Sie den tatsächlichen Wiederherstellungsweg gegen vereinbarte Ziele. Die Anleitung muss auch jemand nutzen können, der den Piloten nicht aufgebaut hat.
Planen Sie den Ausfall einer Abhängigkeit ebenso wie den eines Hosts. Entscheiden Sie, ob die Anwendung ohne Retrieval weiterläuft, Modellanfragen bei einem Connector-Vorfall stoppen sollen und wie Nutzer informiert werden. Ist ein Modellwechsel eine Notfalloption, validieren Sie ihn vorher statt während eines Ausfalls zu improvisieren.
Machen Sie Updates und Rollback zum definierten Betriebsprozess
Pflegen Sie ein Inventar von Modellversionen, Laufzeiten, Treibern, Containerimages, Harness-Abhängigkeiten und MCP-Diensten. Fixieren Sie die Komponenten, die eine Freigabe reproduzierbar machen. Prüfen Sie Anbieteränderungen, Lizenzen und Sicherheitshinweise in einem zu den Supportvereinbarungen passenden Prozess.
Erproben Sie Änderungen vor dem Produktiveinsatz. Wiederholen Sie Qualitäts-, Zugriffsgrenzen- und Werkzeugaktionstests nach Updates an Modell, Prompt, Retrieval oder Connector. Der Leitfaden zu KI-Pentesting und KI-Tests beschreibt den Prüfungsumfang. Ein Paketupdate kann erfolgreich sein, obwohl das Anwendungsverhalten danach unakzeptabel wird.
Definieren Sie Rollback für Software und Zustand. Ein altes Containerimage stellt weder ein geändertes Indexschema noch eine bereits ausgeführte externe Aktion automatisch zurück. Bewahren Sie kompatible Konfigurationen auf und prüfen Sie die zum Änderungsfall passenden Wiederherstellungsschritte. Dokumentieren Sie Freigabeentscheidung und verbleibende Einschränkungen.
Erproben Sie den Start mit einer begrenzten Gruppe berechtigter Nutzer und realistischen Aufgaben. Prüfen Sie Supportweg, absichtlich unterbrochene Abhängigkeit und Rückkehr zur vorherigen Freigabe. Dokumentieren Sie Erkenntnisse und notwendige Korrekturen vor erweitertem Zugriff. Diese Probe sollte zeigen, dass Menschen den Dienst betreiben können und nicht nur, dass das Modell Fragen beantwortet.
Vereinbaren Sie Administrationsumfang und Übergabenachweise
Laufende KI-Systemadministration sollte betreute Systeme, Supportzeiten, Eskalationsweg, Updateverantwortung und Berichtsrhythmus benennen. Trennen Sie Infrastrukturwartung von Entscheidungen über akzeptables Modellverhalten. Beide benötigen Verantwortliche, auch wenn ein Team den gesamten Service erbringt.
Fordern Sie Architektur- und Datenflussdiagramme, Zugriffsinventare, Bereitstellungsnachweise, Dashboards, Wiederherstellungsanleitungen, Evaluierungsergebnisse und Betriebshandbücher. Benennen Sie Verantwortliche für Modellwahl, Dokumentquellen und Werkzeugfreigaben. Dokumentieren Sie erwarteten Verbrauch und ein Verfahren zur Kostenprüfung bei veränderter Nutzung.
Unser Leitfaden zu technischen KI-Schulden erklärt, warum fehlende Verantwortung teuer wird. Diese Checkliste übersetzt das Problem in Übergabeentscheidungen. Bei anwendbaren regulatorischen Anforderungen sollten relevante Unterlagen erhalten bleiben, ohne Infrastrukturadministration als Ersatz für das gesamte Konformitätsverfahren darzustellen.
Für eine geplante Bereitstellung oder die Prüfung einer bestehenden KI-Umgebung sprechen Sie mit ObsidianCorps über Anwendungsfall, Datenvorgaben und Architektur. Wir können die Infrastrukturarbeit und Administrationsverantwortung festlegen, die das System nach dem Start nutzbar halten.
