11 Min. Lesezeit · KI · Juni 2026

Predictive Maintenance mit KI.

Ungeplante Stillstände sind in der Produktion teuer: Eine Maschine, die mitten in der Schicht ausfällt, reißt Liefertermine, blockiert nachgelagerte Stationen und verlangt oft teure Express-Ersatzteile. Predictive Maintenance verspricht, solche Ausfälle vorherzusehen, bevor sie passieren. KI kann dazu einen echten Beitrag leisten — aber nur unter Bedingungen, die viele Unternehmen erst schaffen müssen. Dieser Artikel ordnet ehrlich ein, was geht und was nicht.

Drei Wartungsstrategien — und wo KI ansetzt.

Um Predictive Maintenance einzuordnen, hilft der Vergleich mit den älteren Ansätzen:

Reaktiv: Repariert wird, wenn etwas kaputt ist. Günstig in der Planung, teuer im Ausfall. Für unkritische Anlagen oft trotzdem die richtige Wahl.
Präventiv: Gewartet wird nach festem Intervall — alle 500 Betriebsstunden, jedes Quartal. Verhindert viele Ausfälle, tauscht aber häufig noch funktionierende Teile und kostet so unnötig.
Vorausschauend (predictive): Gewartet wird, wenn der tatsächliche Zustand es nahelegt. Ziel ist der Eingriff zur richtigen Zeit — nicht zu früh, nicht zu spät.

KI setzt bei der dritten Strategie an: Aus dem laufenden Zustand einer Anlage soll abgeleitet werden, ob und wann ein Eingriff nötig ist. Wichtig ist die nüchterne Erwartung: Predictive Maintenance ist kein Allheilmittel, sondern lohnt sich vor allem dort, wo Ausfälle wirklich teuer sind und sich überhaupt durch messbare Vorboten ankündigen.

Die Voraussetzung, an der die meisten scheitern: Daten.

Der häufigste Grund für gescheiterte Projekte ist nicht das Modell, sondern fehlende oder schlechte Daten. Ein Modell kann nur lernen, was sich in den Daten abzeichnet. Konkret braucht es:

Aussagekräftige Sensorik: Vibration, Temperatur, Stromaufnahme, Druck, Drehzahl — je nach Maschine. Wo keine Sensoren sitzen, gibt es nichts zu lernen.
Genügend Historie: Modelle erkennen Verschleißmuster nur, wenn diese Muster in der Vergangenheit vorkamen. Bei seltenen Ausfällen fehlen schlicht die Beispiele.
Dokumentierte Ereignisse: Wann ist tatsächlich was ausgefallen? Ohne saubere Schadens- und Wartungshistorie lässt sich kein Modell sinnvoll trainieren oder auch nur bewerten.
Verlässliche Datenqualität: Lücken, fehlerhafte Sensoren und uneinheitliche Zeitstempel kosten in der Praxis mehr Aufwand als das eigentliche Modellieren.

Wer hier ehrlich hinschaut, stellt oft fest: Der erste Schritt ist nicht KI, sondern eine ordentliche Datenerfassung. Das ist unspektakulär, aber unvermeidlich. Ein KI-Projekt ohne tragfähige Datenbasis ist ein Versprechen ohne Fundament.

Was die KI konkret tut: zwei Grundaufgaben.

Hinter „Predictive Maintenance“ stecken meist zwei unterschiedliche Aufgabentypen, die man nicht verwechseln sollte:

Anomalieerkennung beantwortet die Frage: „Verhält sich die Maschine gerade anders als im Normalbetrieb?“ Dafür lernt ein Modell das normale Schwingungs- und Sensorprofil und schlägt Alarm, wenn der aktuelle Zustand davon abweicht. Das ist vergleichsweise gut machbar und braucht keine Beispiele für jeden möglichen Schaden — nur ein sauberes Bild des Normalzustands.

Restlebensdauer-Schätzung (englisch RUL, Remaining Useful Life) beantwortet die viel schwerere Frage: „Wie lange läuft das Bauteil noch?“ Dafür braucht es viele Beispiele kompletter Verschleißverläufe bis zum Ausfall. Genau die hat man in der Praxis selten in ausreichender Zahl, weil man Maschinen normalerweise nicht absichtlich kaputtgehen lässt. Deshalb sind belastbare RUL-Aussagen deutlich anspruchsvoller als reine Anomaliemeldungen — und sollten nie unkritisch als exakte Zahl verkauft werden.

Ein einfaches, ehrliches Anomalie-Setup.

Man muss nicht mit dem komplexesten Modell starten. Oft bringt ein robuster, nachvollziehbarer Ansatz mehr als eine undurchschaubare Blackbox. Ein vereinfachtes Beispiel: Aus dem Normalbetrieb werden statistische Kennwerte gelernt, gegen die der laufende Betrieb geprüft wird.

import numpy as np

# Trainingsphase: nur Daten aus gesichertem
# Normalbetrieb verwenden!
def lerne_normalprofil(vibration_normal: np.ndarray):
    return {
        "mittel": vibration_normal.mean(),
        "streuung": vibration_normal.std(),
    }

# Laufender Betrieb: Abweichung in Streuungen messen
def pruefe(messwert: float, profil: dict) -> dict:
    abweichung = abs(messwert - profil["mittel"])
    # Wie viele Standardabweichungen entfernt?
    score = abweichung / max(profil["streuung"], 1e-9)
    status = "ok"
    if score > 3:        # weit ausserhalb des Normalen
        status = "alarm"
    elif score > 2:
        status = "beobachten"
    return {"score": round(score, 2), "status": status}

# Wichtig: Ein einzelner Ausreisser ist noch kein
# Schaden. Erst ein anhaltender Trend ueber viele
# Messungen sollte einen Eingriff ausloesen.

Dieses Beispiel ist bewusst simpel — echte Systeme arbeiten mit Frequenzanalysen, mehreren Sensoren und gelernten Modellen. Aber das Prinzip bleibt: Ein klar definierter Normalzustand, eine messbare Abweichung und — ganz entscheidend — die Unterscheidung zwischen einem einzelnen Ausreißer und einem anhaltenden Trend. Wer auf jeden einzelnen Ausschlag mit einem Alarm reagiert, produziert Fehlalarme und verspielt das Vertrauen der Instandhalter.

Das Kernproblem: Fehlalarme und verpasste Ausfälle.

Jedes Vorhersagesystem balanciert zwischen zwei Fehlern, die sich nicht gleichzeitig minimieren lassen:

Fehlertyp	Folge
Fehlalarm (Alarm ohne echten Schaden)	Unnötige Wartung, Vertrauensverlust, irgendwann ignorieren die Mitarbeiter die Warnungen
Verpasster Ausfall (kein Alarm trotz Schaden)	Genau der teure Stillstand, den man verhindern wollte

Wo man die Schwelle setzt, ist eine betriebswirtschaftliche, keine technische Entscheidung: Wie teuer ist ein Fehlalarm gegenüber einem verpassten Ausfall? Bei einer kritischen, teuren Anlage darf das System ruhig empfindlicher sein; bei einer unkritischen Maschine wären ständige Fehlalarme teurer als der seltene Ausfall. Diese Abwägung gehört explizit getroffen und nicht dem Modell überlassen.

Vorgehen in Stufen — bewährt und risikoarm.

Wie bei jeder KI-Einführung gilt: klein anfangen, am wirtschaftlichsten Punkt, mit messbarem Erfolg. Ein bewährter Weg:

Engpass identifizieren: Welche eine Anlage verursacht die teuersten oder häufigsten ungeplanten Stillstände? Dort beginnt man — nicht überall gleichzeitig.
Datenlage prüfen: Gibt es Sensorik und Historie? Wenn nicht, ist das Nachrüsten der erste Schritt, nicht das Modell.
Schattenbetrieb: Das System läuft mit und erzeugt Warnungen, ohne dass danach gehandelt wird. So lässt sich messen, wie gut es echte Probleme früh erkennt und wie viele Fehlalarme es produziert.
Mit der Instandhaltung verzahnen: Erst wenn die Erkennung verlässlich ist, werden Warnungen in den Wartungsplan eingebunden — als Entscheidungshilfe, nicht als Befehl.
Ausweiten mit Augenmaß: Eine Anlage nach der anderen, jeweils mit ehrlicher Erfolgsmessung.

Der Schattenbetrieb ist dabei der wichtigste Schritt. Er kostet wenig, schafft aber Klarheit über die tatsächliche Trefferquote, bevor irgendjemand sich auf das System verlässt. Wer diesen Schritt überspringt, kauft die Katze im Sack.

Wo Predictive Maintenance an Grenzen stößt.

Damit die Erwartung realistisch bleibt, gehören die Grenzen klar benannt:

Plötzliche Ausfälle: Manche Defekte kündigen sich kaum an — ein Materialbruch ohne Vorboten lässt sich nicht vorhersagen, egal wie gut das Modell ist.
Seltene Schäden: Tritt ein bestimmter Defekt nur alle paar Jahre auf, fehlen die Beispiele, um ihn zuverlässig zu lernen.
Veränderte Betriebsbedingungen: Neue Produkte, andere Materialien oder geänderte Lasten können ein eingelerntes Normalprofil entwerten. Modelle müssen gepflegt werden.
Keine garantierten Zahlen: Eine Restlebensdauer ist eine Schätzung mit Unsicherheit, keine Zusage. Wer „die Maschine fällt in genau X Tagen aus“ verspricht, übertreibt.

Diese Grenzen sind kein Argument gegen Predictive Maintenance — sie sind ein Argument dafür, das System als Frühwarn- und Entscheidungshilfe zu verstehen, nicht als Orakel. Der erfahrene Instandhalter bleibt im Spiel; die KI macht ihn nur früher und gezielter aufmerksam.

Lokal oder Cloud, gekauft oder gebaut?

Eine praktische Frage, die früh auftaucht: Wo läuft das System, und baut man es selbst oder kauft man eine fertige Lösung? Beide Entscheidungen hängen vom konkreten Fall ab, und beide werden gern zu schnell getroffen.

Viele Maschinen- und Anlagenhersteller bieten inzwischen eigene Zustandsüberwachung an — teils als Cloud-Dienst, teils integriert in die Steuerung. Das kann der schnellste Weg sein, wenn es zur eigenen Anlage passt. Der Preis ist eine gewisse Abhängigkeit vom Anbieter und oft begrenzte Anpassbarkeit. Eine selbst aufgebaute Lösung ist flexibler und hält die Daten im Haus, kostet aber Aufbau-, Pflege- und Know-how-Aufwand, den man ehrlich einkalkulieren muss. Für viele Mittelständler ist der sinnvolle Mittelweg, mit einer überschaubaren eigenen Auswertung an einer Anlage zu starten und erst bei nachgewiesenem Nutzen über eine breitere Plattform nachzudenken.

Bei der Cloud-Frage spielt der Datenschutz eine Rolle: Maschinendaten sind selten personenbezogen, können aber Betriebsgeheimnisse enthalten. Wer Sensordaten an einen externen Dienst gibt, sollte Datenstandort und vertragliche Grundlagen klären. Das ist keine Rechtsberatung, gehört aber vor dem ersten Datenexport bedacht — nicht danach.

Den wirtschaftlichen Nutzen ehrlich rechnen.

Bevor ein Projekt startet, lohnt eine nüchterne Rechnung: Was kostet ein ungeplanter Stillstand der betreffenden Anlage wirklich — in Stillstandzeit, Folgekosten, Liefertreue? Und wie oft tritt er auf? Erst diese Zahl macht den möglichen Nutzen greifbar und verhindert, dass man viel Aufwand in die Überwachung einer Anlage steckt, deren Ausfall kaum wehtut.

Dem Nutzen stehen die Kosten gegenüber: Sensorik nachrüsten, Datenanbindung, Modellaufbau und — oft unterschätzt — die laufende Pflege. Predictive Maintenance ist kein Projekt, das man einmal aufsetzt und dann vergisst; Modelle müssen mit veränderten Bedingungen mitgepflegt werden. Wer beide Seiten ehrlich gegenüberstellt, erkennt schnell, an welcher Anlage sich der Aufwand lohnt und an welcher nicht. Genau diese Auswahl ist wichtiger als jede technische Detailentscheidung.

Was ich aus der Praxis mitgebe.

Daten zuerst, Modell später. Ohne Sensorik, Historie und saubere Schadensdokumentation kein belastbares Ergebnis — das ist die häufigste Stolperstelle.
Anomalieerkennung vor Restlebensdauer. „Etwas ist anders“ ist machbar; „es fällt in X Tagen aus“ ist deutlich anspruchsvoller und unsicherer.
Fehlalarme ernst nehmen. Zu viele Warnungen zerstören das Vertrauen schneller als ein verpasster Ausfall. Die Schwelle ist eine Geschäftsentscheidung.
Im Schattenbetrieb messen. Erst die echte Trefferquote kennen, dann sich darauf verlassen.
Klein und am Engpass starten. Die teuerste Anlage zuerst, nicht der ganze Maschinenpark auf einmal.

Sie überlegen, ob Predictive Maintenance für Ihre Anlagen sinnvoll ist — und ob die Datenlage trägt? Unverbindlich anfragen — wir prüfen ehrlich Sensorik, Historie, den wirtschaftlichsten Einstiegspunkt und realistische Erwartungen.