KI-Agenten in der Anlagentechnik: wie ein Agent für HLK und Klimatechnik konkret aussieht.

Ein KI-Agent besteht — jenseits allen Buzzwords — aus vier Bausteinen: einem Ziel, einem Satz Tools, einer Schleife und einem Sprachmodell, das in dieser Schleife klassifiziert oder Hypothesen formuliert. Spannend wird's, wenn man diese vier Bausteine in einen konkreten operativen Kontext kippt. Fürs Portfolio Management haben wir das im Forecast-Watchdog-Beitrag gezeigt. Diesmal geht es um die Anlagentechnik — HLK, Klima- und Kältetechnik.

Die Domäne ist auf den ersten Blick unspektakulär, aus dem Alltag eines Facility- oder Betriebstechnik-Managers aber sofort wiedererkennbar: hunderte Sensor-Kanäle pro Anlage, Betriebsdaten, die im Wartungssystem verschwinden, Störungen, die erst an einem Freitag Nachmittag als E-Mail von der Haustechnik kommen. Ein KI-Agent kann hier eine ähnliche Rolle spielen wie in der Vermarktung — nur mit anderen Datenstrukturen und einer anderen Zielgröße.

In einem Satz

Der Anlagen-Wächter ist ein autonom laufender Software-Agent, der stündlich die Betriebsdaten Ihrer HLK-, Klima- und Kältetechnik-Anlagen mit dem erwarteten Betriebsmuster vergleicht, Auffälligkeiten nach Ursache klassifiziert (Sensor-Drift, Verschleiß, falscher Sollwert, ungewöhnliche Last) und Ihnen eine konkrete Handlungsempfehlung ins Cockpit legt — bevor die Anlage in einen Störungsmodus geht oder die Instandhaltung reaktiv ausrücken muss.

Warum gibt es ihn?

In der operativen Realität eines Facility- oder Anlagentechnik-Verantwortlichen entstehen laufend Diskrepanzen zwischen erwartetem und tatsächlichem Betrieb. Drei Ursachen dominieren:

Ursache	Wer entdeckt es heute?	Wann wird's teuer?
Sensor-Drift (Fühler altert, misst falsch)	oft niemand — bis eine Anlage außer Toleranz läuft	bei der nächsten Wartungs-Rechnung oder als Energiekosten-Anomalie
Verschleiß (Kompressor, Ventilator, Pumpe)	reaktiv beim Ausfall, oft mit Störmeldung Freitag Nachmittag	Ausfallzeit, Notdienst-Zuschläge, ggf. Kollateralschäden
Falscher Sollwert / Last-Anomalie	rückblickend, oft im Monatsreport	über den Monat als überhöhte Energiekosten kumuliert

Ein Facility-Portfolio mit 20+ Anlagen — Fernwärme-Zentrale, Krankenhaus-Klima, Rechenzentrums-Kälte, Industriehalle — lässt sich nicht mehr per Auge überwachen. Die klassische Gebäudeleittechnik (GLT) meldet Störungen mit harten Schwellwerten, das GLT-Dashboard zeigt Kurven im Nachhinein. Die Lücke dazwischen — kontextuelle Muster, Ursachen-Klassifikation, konkrete Handlungsempfehlung — bleibt offen.

Der Anlagen-Wächter ersetzt weder die GLT noch die Wartungsfirma. Er ersetzt die nicht-mehr-mögliche manuelle Sichtkontrolle aller Kanäle über die Zeit.

Was macht der Agent konkret?

Stündlich (anpassbar) durchläuft der Agent je Anlage einen strukturierten Prozess:

• Schritt 1 — Anomalie-Filter. Betriebsdaten der letzten Stunden gegen Baseline (historischer Betrieb, Außen-Wetter, Wochentag).
• Schritt 2 — Evidenz sammeln. Mehrere Tools werden abgefragt: Sensor-Redundanz-Check (mehrere Sensoren am gleichen Punkt), Energieverbrauchs-Vergleich mit Baseline, Wartungshistorie der Anlage, ähnliche Anlagen im Portfolio.
• Schritt 3 — Klassifizieren. Ein LLM klassifiziert die Ursachen-Hypothese: Sensor-Drift, mechanischer Verschleiß, falscher Sollwert, Last-Anomalie, unklar.
• Schritt 4 — Entscheiden. Eine deterministische Regel-Tabelle mappt Hypothese + Severity auf eine konkrete Aktion: keine Aktion, Wartungshinweis, Kontroll-Ticket an Betriebstechnik, kritischer Alert an Bereitschaft.
• Schritt 5 — Aufgabe ins Cockpit. Priorisierter Vorschlag mit Audit-Trail: welche Sensoren, welche Vergleiche, welche Hypothese mit welcher Begründung.

Wer profitiert wie?

Facility- / Anlagen-Manager

• Keine morgendliche Kanal-für-Kanal-Sichtung von 20+ Anlagen. Nur die, die heute Aufmerksamkeit brauchen.
• Reduzierte Notdienst-Einsätze am Wochenende: Anzeichen kommen früher, in geregelter Bearbeitungszeit.

Instandhaltung

• Wartungsvorschläge kontextualisiert — statt „Turnus-Inspektion" ein Hinweis auf die tatsächlich auffällige Baugruppe.
• Sensor-Drift wird identifiziert, bevor die Anlage außerhalb der Toleranz läuft.

Energie- / Nachhaltigkeits-Management

• Energiekosten-Anomalien werden mit einer plausiblen Ursache erklärt — nicht nur „diesen Monat war es teurer".
• Optimierungspotenziale (falsche Sollwerte, Sensor-Fehler mit Betriebs-Effekt) werden benennbar.

Geschäftsführung / Kaufmännische Leitung

• Reduzierte ungeplante Instandhaltungs-Ausgaben, weniger Not-Einsätze.
• Compliance-Audit-Trail für kritische Infrastruktur — jede Empfehlung mit Zeitstempel und Datenlage archiviert.

Wo lohnt sich das besonders?

Der Anlagen-Wächter zeigt seinen Nutzen dort am stärksten, wo mehrere Anlagen gleichzeitig überwacht werden müssen und Ausfälle direkte Betriebs- oder Compliance-Folgen haben:

• Fernwärme-Zentralen und Fernkälte-Verbünde — mehrere Erzeugungseinheiten, saisonale Lastprofile, Anschluss ans Versorger-Reporting.
• Krankenhäuser — kritische Klima- und Kältetechnik in OP, Serverräumen, Laboren, mit hoher Compliance-Last.
• Rechenzentren — Kälte ist geschäftskritisch, Ausfälle kosten sofort. Kontinuierliches Monitoring ist eine Existenz-Frage.
• Industriehallen und Produktionsstandorte — Prozess-Kälte, Klimatisierung, Druckluft. Anlagen-Vielfalt hoch, Personalkapazität für Sichtkontrolle begrenzt.
• Kommunale Multi-Utility-Verbünde — Stadtwerke, die neben Strom und Gas auch Bäder, Verwaltungsgebäude oder Fernwärme betreiben, haben oft ein heterogenes Anlagen-Portfolio ohne dedizierte Monitoring-Rolle.

Architektur in Kurzform

Drei nicht-verhandelbare Architektur-Eigenschaften:

1. Offene Datenanbindung. BACnet, Modbus, OPC UA — die Standards der Gebäudetechnik. Zusätzlich Wetter (DWD) und ggf. Energieverbrauchsdaten aus dem Zählerdatenmanagement.
2. Service-Layer in der Mitte. Die Tools des Agenten (Sensor-Redundanz, Baseline-Vergleich, Wartungshistorie) sind auch als REST-API verfügbar. Dashboards, BI oder Wartungssysteme können dieselben Endpoints nutzen — kein Datensilo.
3. KI als Klassifikator, nicht als Entscheider. Ein LLM klassifiziert die Ursache, eine deterministische Regel-Tabelle entscheidet über die Aktion. Vorhersagbar, testbar, regelkonform. Für Krankenhäuser und Rechenzentren ist das nicht nice-to-have — das ist Bedingung.

Ein typischer Tag mit dem Anlagen-Wächter

07:30. Facility-Manager loggt sich ein. Cockpit zeigt: 1 kritische Aufgabe, 3 Warnungen, 2 Info-Hinweise.

07:31. Kritische Aufgabe öffnen:

Kälte-Aggregat 3 im Serverraum West meldet seit 2 h eine 12 %-Effizienz-Verschlechterung bei gleichbleibender Rücklauftemperatur. Hypothese: Verschmutzung Verflüssiger oder Kältemittel-Mangel. Empfehlung: Wartung heute noch prüfen.

Daneben der Audit-Trail: welche Sensoren, welche Vergleichsdaten, warum das LLM auf „Verflüssiger oder Kältemittel" gekommen ist. Der Facility-Manager kann die Empfehlung einschätzen, nicht nur abnicken.

07:35. Ticket an die Wartungsfirma raus. Aufgabe als „in Bearbeitung" markiert. Beim nächsten Lauf um 08:30 legt der Agent keinen Duplikat-Alert an.

08:00. Eine der drei Warnungen: „Klimaanlage Verwaltungstrakt läuft seit 3 Tagen leicht überhöhter Energie-Baseline. Hypothese: falscher Sollwert nach Urlaubszeitraum-Modus." Facility-Manager prüft, korrigiert.

Mittags. Nichts. Normalbetrieb. Der Agent läuft weiter, meldet sich, wenn etwas kritisch wird.

Was unterscheidet das von klassischer GLT und Wartungssoftware?

	GLT / SCADA	Wartungssoftware / CAFM	Anlagen-Wächter
Datenfokus	Live-Messwerte pro Kanal	Wartungshistorie, Turnusse	Kanal-Daten im Kontext Zeit, Wetter, Portfolio
Reaktion	Alarm bei Schwellwerten	Turnus-Termine	Hypothese + Handlungsempfehlung
Ursachenanalyse	nein	nein	ja, klassifiziert
Skalierung	pro Anlage konfiguriert	manuell gepflegt	autonom über das Portfolio
Erweiterbarkeit	meist proprietär	meist proprietär	Standard-API, offene Protokolle

Der Anlagen-Wächter ersetzt weder GLT noch CAFM. Er schließt die Lücke dazwischen — genau dort, wo heute niemand systematisch hinschaut.

Häufige Fragen

Was passiert bei einer falschen Klassifikation?

Die deterministische Regel-Tabelle fängt harte Signale ab: wenn ein Sensor 0 misst, obwohl die Anlage läuft, kommt der kritische Alert trotzdem — unabhängig davon, was das LLM sagt. Die KI verbessert die Fälle in der Grauzone, sie bestimmt nicht die kritischen.

Was ist mit Datenschutz?

Anlagendaten sind in der Regel keine personenbezogenen Daten. Bei Krankenhaus- oder Verwaltungs-Klimatisierung ist trotzdem eine sensible Umgebung — deshalb sind on-prem-Deployments und Sovereign Cloud die Regel-Optionen, nicht der Sonderfall.

Wie steht es um KRITIS?

Für kritische Infrastruktur (Krankenhäuser, Rechenzentren, Fernwärme-Zentralen mit KritisV-Relevanz) ist eine on-prem-fähige Architektur mit Modell-Versionierung und Audit-Trail Standard. Cloud-API-Abhängigkeiten für die LLM-Klassifikation werden hier bewusst vermieden.

Wie startet ein Projekt?

Über einen Agent Sprint — ein KI-Agent für einen konkreten Anlagen-Use-Case, gegen vorab definierte Acceptance-Kriterien, Festpreis. Wenn der Proof trägt, wird auf mehr Anlagen ausgerollt.

Zusammenfassung

Ein KI-Agent für HLK- und Klimatechnik ist keine Zukunftsmusik — es ist die gleiche Vier-Bausteine-Struktur, die auch in der Vermarktung oder in der Marktkommunikation funktioniert, angewandt auf die Sensor-Kanäle und Betriebsdaten der Anlagentechnik.

Der ehrliche Nutzen liegt nicht in einer Buzzword-Vision, sondern in einer schlichten Beobachtung: Ein Facility-Verantwortlicher kann 20+ Anlagen mit hunderten Sensor-Kanälen nicht mehr täglich per Auge sichten. Ein Agent macht diese Sichtung — und legt dem Menschen eine priorisierte, begründete Aufgabenliste vor. Nicht mehr, nicht weniger.

Reaktion nicht mehr am Ausfall, sondern an der Abweichung. Ohne dass jemand jede Anlage manuell durchklicken muss. Audit-fähig, regelkonform, erweiterbar.