Lokale KI ist nicht automatisch offlinefähig

Kurzfassung: Ein Modell auf dem Gerät kann weiterrechnen, während die Anwendung bereits an fehlender Anmeldung, veralteten Daten oder einer unerreichbaren Schnittstelle scheitert. Unternehmen sollten deshalb einzelne Funktionen ohne Cloud-Verbindung abnehmen – einschließlich Wiederverbindung und Ablauf lokaler Zugangsbelege.

Die Verbindung fällt aus. Der Rechner läuft weiter, das Modell ist geladen, genügend Speicher ist vorhanden. Trotzdem steht der Arbeitsablauf. Das nächste Gerät kann sich nicht anmelden. Eine Bestandsauskunft fehlt. Oder ein Ergebnis wartet auf die Bestätigung eines zentralen Dienstes.

Wer lokale KI beschafft, sollte genau diesen Fall prüfen. Der Ort der Modellrechnung sagt wenig darüber aus, welche betriebliche Leistung ohne Verbindung erhalten bleibt. Entscheidend ist, welche Abhängigkeiten vor und nach der Inferenz liegen – also vor und nach der Berechnung des Modellergebnisses.

Lokale Rechnung ist nur ein Teil der Anwendung

AWS beschrieb bereits bei der Einführung von IoT Greengrass 2.0 im Dezember 2020, wie Komponenten für maschinelle Inferenz direkt auf Geräten eingesetzt werden können. Das ist keine neue Produkteinführung. Die heute verfügbare Dokumentation zeigt aber weiterhin eine wichtige Grenze: Lokale Verarbeitung und unabhängiger Betrieb sind verschiedene Eigenschaften.

Besonders anschaulich wird das bei der Offline-Authentifizierung von Geräten. Dabei können bekannte Client-Geräte eine Verbindung zu einem lokalen Greengrass-Core-Gerät herstellen, obwohl dieses die Cloud nicht erreicht. Für die erste Verbindung eines Clients benötigt das Core-Gerät dagegen eine Cloud-Verbindung. Es lässt die Registrierung und das Zertifikat prüfen und speichert die Informationen lokal. Bei einer späteren Verbindung kann es auf diese gespeicherten Angaben zurückgreifen, wenn der Cloud-Dienst nicht erreichbar ist.

Auch dieser Zustand gilt nicht unbegrenzt. AWS nennt eine konfigurierbare Vertrauensdauer für die gespeicherten Informationen. Der Standardwert beträgt eine Minute; laut Dokumentation schaltet das die Offline-Authentifizierung praktisch aus. AWS empfiehlt, die Einstellung sowohl an den Sicherheitsanforderungen als auch an der erwarteten Dauer ohne Cloud-Verbindung auszurichten.

Der Beleg betrifft die Geräteauthentifizierung dieses Produkts. Er sagt nicht, dass beliebige KI-Anwendungen nach einer Minute ausfallen. Er macht vielmehr eine allgemeine Beschaffungsfrage konkret: Kann die lokal gerechnete Funktion auch dann genutzt werden, wenn ihre Zugangsvoraussetzungen nicht mehr zentral geprüft werden können?

Eine erfolgreiche Vorführung mit bereits angemeldeten Geräten beantwortet das noch nicht. Ebenso wenig beweist sie, dass ein Ersatzgerät während des Ausfalls eingebunden werden kann.

Der Ausfall hat eine Dauer und eine Vorgeschichte

Ein kurzer Verbindungstest kann falsche Sicherheit erzeugen. Sind Zugangsbelege, Daten und benötigte Dateien noch gespeichert, funktioniert die Anwendung zunächst. Erst später läuft ein Beleg ab, eine Datenkopie wird zu alt oder ein Gerät muss neu starten.

Deshalb muss ein Offline-Test unterschiedliche Ausgangszustände unterscheiden. Ein bereits verbundener Client ist ein anderer Fall als derselbe Client nach einem Neustart. Ein bekanntes Gerät ist ein anderer Fall als ein neu hinzukommendes. Eine Anwendung mit vollständigen lokalen Daten kann mehr leisten als eine, die kurz vor dem Ausfall nur einen Teil davon erhalten hat.

Für einen hypothetischen Maschinenbauer könnte das bedeuten: Eine lokale KI ordnet Kamerabilder einer Qualitätsklasse zu. Die eigentliche Berechnung braucht keinen Cloud-Aufruf. Ob die Teile anschließend freigegeben werden dürfen, hängt aber zusätzlich von der aktuellen Prüfvorschrift, der Zuordnung zum Auftrag und dem Zugang des Prüfgeräts ab.

Die Bildklassifikation könnte also weiterlaufen, während die verbindliche Freigabe gesperrt bleibt. Das muss kein Fehler sein. Es kann die richtige Grenze sein, wenn eine aktuelle Prüfvorschrift nicht vorliegt. Problematisch wäre nur, wenn Einkauf und Produktion unter „offlinefähig“ beide Leistungen verstanden hätten, der Anbieter aber lediglich die Bildauswertung zugesagt hat.

Hier gehört die Entscheidung in den Fachbereich: Welche Information darf wie lange fehlen, ohne dass ein Ergebnis unbrauchbar oder eine Handlung unzulässig wird? Der Betrieb klärt anschließend, ob sich diese Grenze technisch einhalten und erkennen lässt.

Weiterarbeiten braucht begrenztes Vertrauen

Gespeicherte Zugangsbelege ermöglichen Betrieb ohne laufende zentrale Prüfung. Gleichzeitig können sie Änderungen am zentralen Berechtigungsstand während der Trennung nicht unmittelbar berücksichtigen. Eine längere lokale Vertrauensdauer ist daher nicht einfach ein besserer Verfügbarkeitswert. Sie verändert, wie lange eine frühere Prüfung als ausreichend behandelt wird.

Diese Abwägung sollte nicht beiläufig beim Einrichten des Systems entstehen. Sie gehört zum zugesagten Funktionsumfang. Für eine ungefährliche lokale Anzeige kann ein anderer Zeitraum vertretbar sein als für eine Funktion, die eine Anlage bedient oder externe Geschäftsvorgänge auslöst.

Auch lokale Daten brauchen eine solche Grenze. Eine gespeicherte Anleitung kann weiterhin hilfreich sein, obwohl sie nicht den neuesten Stand hat. Ein gespeicherter Lagerbestand kann dagegen schon nach weiteren Entnahmen eine falsche Lieferzusage erzeugen. „Daten vorhanden“ und „Daten für diese Handlung aktuell genug“ sind verschiedene Prüfergebnisse.

Daraus folgt keine allgemeine Pflicht, jede Anwendung lokal zu betreiben. Manche Funktionen dürfen bei fehlender Verbindung bewusst stoppen. Andere können mit geringerem Umfang weiterarbeiten. Ein Ersatzweg über Menschen ist nur dann eine echte Alternative, wenn diese auch auf die erforderlichen Informationen und Werkzeuge zugreifen können.

Die Abnahme muss mehr als den Stecker prüfen

Als eigene Managementableitung aus dem Greengrass-Beispiel bietet sich eine Funktionsliste an. Sie benennt für jede Leistung die benötigten zentralen Dienste, die lokal verfügbaren Informationen und den erlaubten Zustand bei deren Ausfall. Die Liste sollte so konkret sein, dass sich ein Test daraus ableiten lässt: etwa „bekanntes Prüfgerät verbindet sich erneut“ statt „System funktioniert offline“.

In einer vereinbarten Testumgebung mit ungefährlichen Daten werden dann mindestens diese Fälle geprüft:

• Eine laufende Anwendung verliert die Cloud-Verbindung.
• Ein bekanntes Gerät verbindet sich während der Trennung erneut.
• Ein Gerät oder die lokale Laufzeit startet ohne Cloud-Verbindung neu.
• Die Trennung dauert länger als ein relevantes Gültigkeits- oder Frischefenster.
• Die Verbindung kehrt zurück, während lokale Vorgänge noch offen sind.

Ein neues Gerät während der Trennung ist ein zusätzlicher Prüffall, falls der Betrieb diese Fähigkeit tatsächlich benötigt. Fehlt sie, muss der Ersatzgeräteplan das berücksichtigen. Nicht jedes System muss jeden Fall bestehen; aber der zugesagte Umfang muss erkennbar eingehalten werden.

Bei der Wiederverbindung reicht es nicht, dass das Verbindungssymbol wieder grün wird. Hat die Anwendung Vorgänge gespeichert, muss geprüft werden, welche davon noch ausgeführt werden dürfen. Eine inzwischen erledigte Anfrage darf nicht versehentlich ein zweites Mal wirken. Ein Auftrag, dessen Voraussetzungen sich geändert haben, benötigt eine erneute Prüfung. Das sind Anforderungen an den eigenen Ablauf, keine pauschal zugesicherten Greengrass-Eigenschaften.

Auch die Produktversion gehört ins Testprotokoll. Die AWS-Dokumentation nennt für Offline-Authentifizierung eine Mindestversion, weist aber zugleich darauf hin, dass die ursprüngliche Client-Auth-Version 2.3.0 nicht mehr verfügbar ist, und empfiehlt 2.3.1 oder später. Eine alte Versionsangabe aus einer Präsentation ersetzt deshalb keinen Test des tatsächlich eingesetzten Stands.

Beschafft wird eine Funktion unter Ausfallbedingungen

Die Geschäftsführung muss dafür nicht jede technische Abhängigkeit verstehen. Sie braucht eine klare Zusage: Welche Leistung bleibt bei welcher Trennung wie lange verfügbar, welche Handlung wird gesperrt und woran erkennt der Betrieb den Unterschied?

Fachbereich, IT und Anbieter können daraus eine überprüfbare Leistungsbeschreibung machen. Steht im Angebot nur „lokale KI“, ist die entscheidende Arbeit noch offen. Ein sinnvoller Nachweis nennt den geprüften Gerätestand, die Ausgangszustände, die Dauer der Trennung und das Ergebnis je Funktion.

Damit wird auch der Business Case genauer. Der Wert lokaler KI kann in vermiedenen Unterbrechungen liegen. Dafür zählt jedoch die erhaltene Arbeitsleistung, nicht die bloße Zahl lokaler Modellaufrufe. Rechnet das Modell weiter, während der Prozess auf einen zentralen Zugang wartet, wurde Rechenort gekauft – aber noch keine Offlinefähigkeit.