KI-Agenten im industriellen IoT: von Predictive Maintenance zu autonomem Betrieb

Zwei Jahrzehnte lang bedeutete industrielles IoT vor allem Datenpipelines: Sensoren speisten Zeitreihendatenbanken, Dashboards zeichneten Linien, und irgendwann klickte ein Mensch auf etwas. Dieses Modell funktioniert weiterhin für das Reporting, doch es zerbricht in dem Moment, in dem man vom System verlangt, zu entscheiden. KI-Agenten schließen diese Lücke. Sie nehmen rohe Telemetrie wahr, schließen darüber sowohl mit klassischen Modellen als auch mit großen Sprachmodellen und lösen Aktionen über dieselben MQTT- und OPC-UA-Kanäle aus, die Ihre SPS bereits sprechen. Dieser Artikel zeigt, wie wir bei FSS agentische IoT-Systeme konzipieren, wo die Schutzmechanismen ansetzen und warum ein Yacht-Maschinenraum und eine Hotel-HLK-Anlage architektonisch am Ende identisch aussehen.

Was ein KI-Agent tatsächlich ist (und was nicht)

Ein KI-Agent ist kein Chatbot, den man auf einen SCADA-Bildschirm geschraubt hat. Er ist ein Softwareprozess mit drei beständigen Eigenschaften: Er beobachtet einen Zustandsstrom, er unterhält eine interne Repräsentation von Zielen und Randbedingungen, und er wählt Aktionen, die den Zustand in Richtung der Ziele bewegen. Klassische Automatisierung – PID-Regelkreise, Regel-Engines, Alarmmatrizen – teilt die dritte Eigenschaft, entbehrt jedoch der ersten beiden in irgendeinem flexiblen Sinne. Ein PID-Regler kann nicht darüber schließen, warum eine Sollwertdrift mit einem versagenden Lager drei Meter stromaufwärts korreliert. Ein Agent kann es, weil er Kontext über die Zeit und über Signale hinweg mitträgt.

Der kanonische Agentenkreislauf lautet Wahrnehmung, Planung, Aktion. In einem industriellen Umfeld bedeutet Wahrnehmung das Einlesen von Telemetrie aus vernetzten Geräten, von Anreicherungsdaten aus ERP- oder Wartungssystemen sowie von unstrukturierten Signalen wie Bedienernotizen oder Kamerabildern. In der Planung findet das Schlussfolgern statt: klassische Anomalieerkennung, Vektorähnlichkeitssuche gegen historische Fehlersignaturen oder ein LLM-Aufruf gegen einen Werkzeugkatalog. Die Aktion ist das Schließen des Kreislaufs – das Veröffentlichen einer Sollwertänderung, das Öffnen eines Tickets, das Alarmieren eines Technikers oder, im vollautonomen Modus, das direkte Ansteuern eines Aktors.

Referenzarchitektur für agentisches IoT

Ein produktionsreifer Agentenstack hat fünf Schichten. Wir betreiben Varianten davon auf Azure für Hospitality-Kunden und auf hybriden Edge-Cloud-Topologien für maritime Kunden, bei denen Satelliten-Uplinks nur zeitweise verfügbar sind.

Geräteschicht – Leiterplatten, Sensoren, Gateways. Die Firmware veröffentlicht strukturierte Telemetrie über MQTT mit QoS 1, mit feldgenauen Zeitstempeln aus einer disziplinierten RTC.
Einlesen und Normalisierung – Azure Event Hubs oder IoT Hub verteilen Nachrichten an einen Stream-Prozessor, der Einheiten auflöst, Device Twins anwendet und kanonische Ereignisse ausgibt.
Zustand und Speicher – ein Hot Store (Redis, Cosmos DB) für den aktuellen Gerätezustand, ein Cold Store (ADLS, Parquet) für historisches Training und ein Vektorspeicher für embedding-basiertes Abrufen.
Agenten-Laufzeit – der Kreislauf selbst, typischerweise containerisiert, mit Werkzeugdefinitionen, Prompt-Vorlagen und einer deterministischen Policy-Engine, die jeden LLM-Aufruf umschließt.
Aktuierung und Audit – signierte Befehlsnachrichten zurück an die Geräte, plus ein unveränderliches Protokoll jeder Entscheidung, die der Agent getroffen hat, jedes Werkzeugs, das er aufgerufen hat, und jeder Eingabe, die er gesehen hat.

Die Audit-Schicht ist nicht verhandelbar. In dem Moment, in dem ein Agent den physischen Zustand verändern kann, müssen Sie in der Lage sein, sechs Monate später exakt zu rekonstruieren, warum er getan hat, was er getan hat. Wir behandeln das Entscheidungsprotokoll als erstklassiges Datenprodukt, abfragbar nach Ticket-ID, Geräte-ID und Bedienername.

LLM-gestützte Anomalieerkennung

Klassische Anomalieerkennung – Isolation Forests, Autoencoder, statistische Prozesskontrolle – leistet nach wie vor den Großteil der Schwerarbeit. LLMs kommen dort ins Spiel, wo klassische Methoden am schwächsten sind: Erklärung, Korrelation über heterogene Signale hinweg und menschenlesbare Triage. Ein typisches Muster ist ein zweistufiger Detektor. Stufe eins ist ein schnelles statistisches Modell, das nah an den Daten läuft. Stufe zwei ist ein Agent, der, wenn Stufe eins auslöst, die letzte Stunde relevanter Signale heranzieht, die drei ähnlichsten historischen Vorfälle aus einem Vektorindex abruft und einen strukturierten Triage-Bericht erstellt.

Der Kniff besteht darin, das LLM an der kurzen Leine zu halten. Wir beschränken die Ausgabe auf JSON-Schemata, erzwingen Werkzeugaufrufe statt Freitext für jede Datenabfrage und lassen das Modell niemals Gerätebefehle improvisieren. Das Modell schlägt vor; eine deterministische Policy-Engine entscheidet. Es ist dieselbe Disziplin, die wir beim Bau von Codex-artigen Code-Assistenten für unsere eigenen Engineering-Teams anwenden – das Schlussfolgern ist generativ, die Ausführung ist abgeriegelt.

Vektor-Embeddings für Predictive Maintenance

Predictive Maintenance bedeutete historisch Modelle pro Anlage: einen Regressor pro Pumpe trainieren, vierteljährlich neu trainieren, neu ausrollen. Das skaliert schlecht über Flotten von Tausenden. Embedding-basiertes Abrufen verändert die Ökonomie. Wir extrahieren Merkmalsvektoren fester Länge aus jedem Wartungsereignis – Vibrationsspektrum, Temperaturverlauf, Stromaufnahme, Alter, letzte Wartung – und speichern sie in einer Vektordatenbank. Wenn ein neues Ereignis eintrifft, liefert die Ähnlichkeitssuche die nächstgelegenen historischen Treffer samt der zugehörigen Lösungen zurück.

# Pseudocode für embedding-basiertes Fehler-Abrufen
event_vector = encode(telemetry_window, asset_metadata)
neighbors = vector_index.search(event_vector, k=5, filter={"asset_class": "centrifugal_pump"})
context = [n.payload for n in neighbors if n.score > 0.82]

proposal = agent.reason(
    current_event=event_vector,
    historical_context=context,
    available_tools=["open_work_order", "adjust_setpoint", "page_engineer"],
)

Dieses Muster funktioniert, weil sich Fehlermodi über Anlagen hinweg auf eine Weise verallgemeinern, wie es die Kennzahlen an der Oberfläche nicht tun. Ein Lagerschaden an einem Hotel-Kaltwassersatz sieht im Merkmalsraum bemerkenswert ähnlich aus wie ein Lagerschaden an einer Yacht-Stabilisatorpumpe. Wir verfügen über eine KI-Infrastruktur, die genau auf diese Art flottenübergreifenden Abrufens abgestimmt ist, und sie übertrifft in unseren Benchmarks durchgängig Modelle pro Anlage, sobald eine Flotte einige Hundert Einheiten überschreitet.

Agenten mit MQTT und OPC-UA integrieren

Agenten sind nutzlos, wenn sie nicht mit dem Feld sprechen können. MQTT ist unsere Standardwahl für Neubauten, weil es sich sauber mit Cloud-Brokern komponieren lässt und die QoS- und Retained-Message-Semantik unterstützt, die Agenten benötigen – wenn Sie diese noch nicht verinnerlicht haben, deckt unsere Einführung in MQTT für IoT die Grundlagen ab. Für Brownfield-Industriestandorte ist OPC-UA unvermeidlich, und der richtige Schritt ist ein Gateway, das OPC-UA-Adressräume mit einer stabilen Namenskonvention in MQTT-Topics überbrückt.

Der Agent abonniert Topic-Muster, nicht einzelne Topics. Ein Fabrik-Agent könnte plant/+/line/+/asset/+/telemetry überwachen, während ein Yacht-Agent vessel/+/system/+/state beobachtet. Topic-Konventionen sind Teil des Vertrags; wir legen sie in jedem Projekt früh fest und versionieren sie in der Geräte-Firmware. Befehls-Topics werden gespiegelt: plant/.../command mit signierten Payloads und einer kurzen TTL, damit ein veralteter Befehl nie noch feuert, nachdem sich eine Netzwerkpartition wieder geschlossen hat.

Den Kreislauf schließen: autonome Steuerung mit Schutzmechanismen

Hier zögern die meisten Teams, und das zu Recht. Einen Agenten den physischen Zustand verändern zu lassen, ist eine andere Risikokategorie, als ihn eine Slack-Nachricht entwerfen zu lassen. Wir verwenden eine vierstufige Autonomieleiter, und jeder Anlagenklasse wird ausdrücklich eine Stufe zugewiesen:

Stufe 0 – Nur beobachten. Der Agent berichtet, schlägt aber nie vor.
Stufe 1 – Vorschlagen. Der Agent schlägt Aktionen vor; ein Mensch muss sie vor der Ausführung genehmigen.
Stufe 2 – Handeln mit Vetorecht. Der Agent führt nach einer Verzögerung aus (typischerweise 30 bis 300 Sekunden), während der ein Mensch abbrechen kann.
Stufe 3 – Autonom. Der Agent handelt sofort innerhalb eines eng begrenzten Aktionsraums, mit Ratenbegrenzungen und Rollback.

Die meisten Anlagen verharren für immer auf Stufe 1 oder Stufe 2, und das ist in Ordnung. Stufe 3 ist Aktionen vorbehalten, die wirklich reversibel, begrenzt und zeitkritisch sind – etwa das Anpassen eines HLK-Sollwerts um weniger als zwei Grad oder das Zuschalten einer Ersatzpumpe in den Betrieb. Alles, was Sicherheitsverriegelungen berührt, bleibt per Richtlinie auf Stufe 0. Die Autonomiestufe ist im Device Twin kodiert und wird von der Policy-Engine durchgesetzt, nicht vom Agenten-Prompt. Wenn ein Modell eine Stufe-3-Aktion an einer Stufe-1-Anlage halluziniert, wird sie abgewiesen, bevor sie je den Broker erreicht.

Human-in-the-Loop-UX

Stufe 1 und Stufe 2 funktionieren nur, wenn die menschliche Schnittstelle schnell ist. Eine Push-Benachrichtigung mit einem Ein-Tipp-Genehmigen oder -Veto, eine klare Zusammenfassung, warum der Agent handeln will, und ein Link zur stützenden Telemetrie. Reibung tötet diese Arbeitsabläufe; wenn eine Genehmigung mehr als zehn Sekunden dauert, hören Bediener auf zu lesen und beginnen abzunicken. Wir bauen diese Oberflächen als Teil unserer Mobile-Control-Leistungen und behandeln sie mit derselben Strenge wie die Firmware.

Edge- vs. Cloud-Bereitstellung von Agenten

Wo der Agent läuft, ist entscheidend. Die Cloud-Bereitstellung ist einfacher: voller Modellzugriff, leichte Iteration, zentralisierte Protokolle. Die Edge-Bereitstellung ist schwieriger, aber unvermeidlich, wenn Latenz zählt, wenn die Konnektivität unzuverlässig ist oder wenn Vorgaben zur Datensouveränität einen Abfluss verbieten. Die pragmatische Antwort ist fast immer hybrid. Ein kleines, destilliertes Modell läuft am Edge für schnelle Kreisläufe – typischerweise Anomalieklassifizierung und einfache Aktionsauswahl. Ein größeres Modell in der Cloud übernimmt die langsamen Kreisläufe – flottenübergreifendes Lernen, Ursachenanalyse und wöchentliches Neutraining.

Am Edge zielen wir auf Hardware, die ein Modell mit 1B bis 3B Parametern bei int8-Präzision ausführen kann: einen NVIDIA Jetson Orin Nano für schwere Lasten, einen i.MX 8M Plus für den mittleren Bereich oder einen gut instrumentierten ESP32-S3 für die einfachsten Mustererkennungsaufgaben. Die Cloud-Seite läuft auf Azure mit Modell-Endpunkten, die unsere Policy-Schicht vorschaltet. Die Aufteilung folgt einer einfachen Regel: Wenn die Aktion in unter einer Sekunde feuern muss, lebt die Entscheidung am Edge. Andernfalls lebt sie in der Cloud.

Anwendungsfälle über Branchen hinweg

Fabrikhalle

Ein Linienagent überwacht Durchsatz, Ausschussrate und OEE in Echtzeit. Wenn der Ausschuss an einer Stanzpresse schleichend steigt, korreliert er ihn mit Vibration und Werkzeugtemperatur, ruft die drei ähnlichsten historischen Episoden ab und empfiehlt entweder eine Reduzierung der Vorschubgeschwindigkeit (Stufe 2) oder einen Werkzeugwechsel (Stufe 1). Das Entscheidungsprotokoll wird nächtlich über dieselben Integrationsmuster, die wir für die ERP-Synchronisierung nutzen, in den BI-Stack des Qualitätsteams exportiert.

Luxushotel

Ein Gebäudeagent verantwortet Gästekomfort und Energiekosten gleichzeitig. Er lernt das thermische Verhalten pro Zimmer, prognostiziert die Belegung aus PMS-Check-ins und konditioniert Zimmer vor der Ankunft vor – alles auf Stufe 3 innerhalb eines engen Sollwertfensters. Wenn ein Gast den Sollwert über das Zimmertablet übersteuert, gibt der Agent sofort nach und protokolliert die Übersteuerung als Trainingsdaten. Energieeinsparungen von 15 bis 25 Prozent sind Routine, ohne jede für den Gast wahrnehmbare Veränderung.

Superyacht

Ein Schiffsagent läuft weitgehend am Edge, weil Satellit teuer und zeitweise ausfällt. Er überwacht die Hotellast-Systeme – HLK, Wassermacher, Grauwasserpumpen – und die Maschinenraum-Subsysteme, mit strikter Trennung zwischen den beiden Domänen. Stufe-2-Aktionen an Hotelsystemen, Stufe 0 nur an allem, was dem Antrieb nahesteht. Wenn das Boot zu einer Marina mit zuverlässiger Konnektivität zurückkehrt, synchronisiert der Edge-Agent sein Entscheidungsprotokoll in die Cloud für flottenweites Lernen über die anderen Schiffe des Eigners hinweg.

Team und Toolchain aufbauen

Agentisches IoT ist keine einzelne Disziplin. Es braucht Firmware-Ingenieure, die Timing und Leistung verstehen, Cloud-Ingenieure, die ereignisgesteuerte Systeme verstehen, ML-Ingenieure, die Evaluierung und Drift verstehen, und Fachexperten, die verstehen, was “sicher” in ihrem Kontext tatsächlich bedeutet. Der größte Fehler, den wir sehen, ist, dass Teams den Agenten als ML-Problem behandeln, obwohl es in Wirklichkeit ein Systemproblem ist. Das Modell ist vielleicht zwanzig Prozent der Arbeit. Die anderen achtzig Prozent sind Verrohrung, Observability und Policy.

Unsere eigene Toolchain stützt sich stark auf agentische Muster, die wir produktisiert haben: Werkzeugregister mit starken Schemata, an Git gebundene Prompt-Versionierung, Evaluierungsgerüste, die historische Vorfälle gegen neue Modellversionen erneut abspielen, und eine Policy-DSL, mit der Fachexperten Randbedingungen ausdrücken können, ohne Python zu schreiben. Nichts davon ist glamourös. Alles davon ist der Unterschied zwischen einer Demo und einem System.

Wo man anfängt

Wenn Sie agentisches IoT zum ersten Mal bewerten, beginnen Sie nicht mit Autonomie. Beginnen Sie mit Erklärung. Verdrahten Sie einen Stufe-0-Agenten, der strukturierte Triage-Berichte für Vorfälle erstellt, die Ihr Team bereits manuell bearbeitet. Messen Sie, wie oft die Diagnose des Agenten mit der schließlichen Grundursache übereinstimmt. Sobald diese Zahl bei einer repräsentativen Stichprobe durchgängig über achtzig Prozent liegt, haben Sie sich das Recht verdient, an einem schmalen Ausschnitt der Anlagen zu Stufe 1 überzugehen. Verdienen Sie sich jede Stufe; setzen Sie sie nicht voraus.

Von Sensor über Erkenntnis zu Aktion ist ein langer Weg, und die Brücken zwischen diesen Etappen sind es, an denen die meisten Projekte scheitern. Wenn Sie durchsprechen möchten, wie eine agentische Architektur für Ihre Flotte aussieht, unser Team baut diese Systeme durchgängig – von der Leiterplatte über die Firmware und die Cloud bis zum Agenten. Beginnen Sie mit unserem Service für vernetzte Geräte oder erkunden Sie die umfassendere IoT-Plattform, die wir darüberlegen.