Warum KI-Agenten an der Maschine laufen, nicht in der Cloud

Die meisten KI-Agenten leben heute in der Cloud. Ein Sensor meldet einen Wert, die Anwendung schickt ihn über das Internet in ein Rechenzentrum, ein großes Modell antwortet, die Antwort läuft zurück. Für einen Chat im Browser ist das in Ordnung. An einer Maschine, die in Millisekunden reagieren muss, an einem Standort ohne stabile Verbindung oder in einer Anlage, deren Daten das Werk nicht verlassen dürfen, ist es das nicht.

Hier stellt sich die Frage anders herum. Warum sollte der Agent überhaupt in der Cloud rechnen und nicht direkt auf dem Gerät? Ein Edge Agent dreht die Topologie um. Die Intelligenz läuft dort, wo die Daten entstehen, auf dem Steuergerät, dem Industrierechner, dem kleinen Board neben der Maschine. Vier nüchterne Gründe sprechen dafür.

Latenz bedeutet Reaktionen in Millisekunden statt Sekunden

Jeder Weg in die Cloud kostet Zeit. Netzwerklaufzeit hin, Antwort zurück, dazu die Verarbeitung im Rechenzentrum. Für eine Anlage, die auf einen Schwellwert reagieren soll, ist das ein Problem. On-Device-KI spart den gesamten Round-Trip. Die Auswertung passiert auf demselben Gerät, an dem der Sensor hängt.

Wichtig ist dabei die Architektur. Der Agent sitzt nie im harten Echtzeit-Regelkreis. Diesen behält der deterministische Controller. Der Agent arbeitet nach dem Muster „Agent als Werkzeug“. Er liest Werte, trifft eine Entscheidung und schreibt Parameter, etwa einen neuen Sollwert, gepuffert zurück. Der Regelkreis läuft ununterbrochen weiter. So bleibt die Reaktion schnell, ohne die Stabilität der Steuerung zu gefährden.

Kosten ohne Dauerstrom in die Cloud

Ein Cloud-Agent kostet bei jedem Aufruf, also Rechenzeit, Token-Strom und Bandbreite. Bei einem Gerät, das rund um die Uhr Sensordaten verarbeitet, summiert sich das zu einem laufenden Posten, der nie aufhört. Lokale KI in der Industrie kehrt das um. Die Auswertung läuft auf vorhandener Hardware, ohne pro Inferenz zu zahlen.

Möglich wird das durch eine Intelligenz-Kaskade. Sie nutzt einfache Regeln, dann klassisches Machine Learning, dann ein kleines Sprachmodell (SLM, 1 bis 3 Mrd. Parameter) direkt auf dem Gerät, dann ein mittelgroßes Open-Weight-Modell, und erst als Ausnahme ein großes Cloud-Modell. Ein großer Teil der industriellen Aufgaben passt auf ein On-Device-SLM. Das große Modell wird die Ausnahme, nicht die Regel.

Konnektivität, weil Anlagen selten zuverlässig online sind

Viele Industrieumgebungen sind offline, abgeschottet oder nur sporadisch verbunden, etwa ein Schiff auf See, eine Fertigungshalle ohne Werks-WLAN an der Maschine oder ein abgelegener Standort im Feld. Ein Cloud-Agent steht in dem Moment still, in dem die Verbindung abreißt, also genau dann, wenn am Standort niemand zuschaut.

Ein Edge Agent ist standardmäßig offline-fähig. Die Engine läuft eigenständig auf dem Gerät, mit dauerhaftem lokalem Speicher für Zustand und Verlauf. Hier gehört die ehrliche Einordnung dazu. Vollständig autark ist der Betrieb nur mit einem lokalen Modell. Cloud-Modell, Websuche und ein entfernter Wissensabruf machen ausgehende Verbindungen. Sie bleiben optional und die Ausnahme. Wer den Agenten mit lokalem SLM betreibt, läuft auch bei tagelang fehlender Verbindung weiter und synchronisiert, sobald wieder eine Leitung da ist.

Datensouveränität hält die Daten im Haus

Sobald Sensordaten, Prozesswerte oder Bilder in eine fremde Cloud wandern, verlässt man die eigene Kontrolle, rechtlich wie technisch. Für viele Betreiber ist das ein Ausschlusskriterium, nicht nur wegen der DSGVO, sondern weil Prozessdaten Betriebsgeheimnisse sind.

On-Device-KI hält die Daten dort, wo sie entstehen. Die Verarbeitung passiert lokal, die Ausführung ist durch Container-Isolation gekapselt, die Verteilung der Images läuft signiert. Der auditierbare, begrenzte Graph macht jederzeit nachvollziehbar, was der Agent tut. Diese Eigenschaften sind als Architekturmerkmal auf den EU Cyber Resilience Act ausgelegt. Sicherheit ist hier kein nachträglicher Aufsatz, sondern Teil der Bauweise.

Ein Beispiel, die abgelegene Pumpstation

Eine Aufbereitungs- und Pumpstation liegt weit außerhalb, angebunden nur über eine wackelige Mobilfunkstrecke. Mehrere Stunden am Tag ist sie faktisch offline. Eine Cloud-Lösung wäre genau dann blind, wenn etwas passiert.

Auf dem lokalen Industrierechner läuft ein Edge Agent. Ein Schwellwert-Trigger mit Hysterese beobachtet Druck und Durchfluss. Übersteigt ein Wert die Grenze, klassifiziert ein lokales SLM die Situation aus dem aktuellen Kontext und dem lokalen Verlauf, schreibt einen angepassten Sollwert gepuffert an die Steuerung und legt das Ereignis im dauerhaften Speicher ab. Der eigentliche Regelkreis läuft die ganze Zeit deterministisch weiter. Kommt die Verbindung zurück, werden die gesammelten Ereignisse an die Zentrale übertragen. Kein Datenpunkt geht verloren, keine Entscheidung wartet auf die Cloud.

So läuft das am Edge

Technisch trägt das eine graph-orientierte Laufzeit. Der Workflow-Graph ist das Programm. Die KI ist nur ein Knoten darin. Das macht den Ablauf deterministisch, einsehbar und begrenzt, kein Black-Box-Agent, der frei agiert, sondern ein klar abgesteckter Pfad.

Dasselbe einzelne Binary läuft auf jeder Hardware, vom Raspberry Pi über ein Jetson-Board bis zum Industrierechner oder x86-Server. Neue Hardware heißt neu ausrollen, nicht neu schreiben. Hardware-Ein- und -Ausgänge wie GPIO, ADC/DAC/PWM, UART/Seriell und MQTT sind erstklassige Knoten gegen echte Linux-Treiber. Trigger reichen von Intervall und Zeitalarm über Schwellwert-mit-Hysterese und Pin-Flanke bis zur eingehenden MQTT-Nachricht.

Das kleine Sprachmodell läuft über einen lokalen, OpenAI-kompatiblen Inferenzserver (etwa llama.cpp) direkt neben der Engine. Wissensbasis und semantische Suche liefern Kontext aus den eigenen Dokumenten. Der dauerhafte lokale Speicher hält Zustand über Neustarts hinweg. Visueller Builder und CLI bauen die Graphen. Der quelloffene Kern ist ohne Konto nutzbar, das Backend ist die Verwaltungs- und Flottenschicht obendrauf, inklusive Agent-Registry, Flotten-Orchestrierung und föderiertem Lernen, mit dem sich Modelle über viele baugleiche Geräte verbessern, ohne Rohdaten zu zentralisieren. From Hardware to Intelligence.

Das Wichtigste in Kürze

• Latenz. Die Auswertung passiert am Gerät, ohne Cloud-Round-Trip. Der Agent schreibt nur gepufferte Parameter und sitzt nie im harten Regelkreis.
• Kosten. Eine Intelligenz-Kaskade hält die meisten Aufgaben auf einem On-Device-SLM, kein laufender Token-Strom in die Cloud.
• Konnektivität. Die Engine ist offline-fähig. Vollständig autark ist sie mit einem lokalen Modell, Cloud-Aufrufe bleiben optional und die Ausnahme.
• Datensouveränität. Daten bleiben lokal. Lokale Ausführung, Container-Isolation und signierte Images sind als Architektur auf den EU Cyber Resilience Act ausgelegt.
• Ein Binary, jede Hardware. Vom Raspberry Pi bis zum Industrierechner neu ausrollen statt neu schreiben.