KI im Maschinenbau: 6 Use-Cases und was sie voraussetzen

Im Maschinenbau funktionieren KI-Projekte dann, wenn die Datengrundlage schon existiert. Sechs Use-Cases tragen sich in der Praxis regelmäßig: Predictive Maintenance, visuelle Qualitätskontrolle, Produktionsplanung, Angebotskalkulation, Service-Anfragen und das Erzeugen technischer Dokumentation. Der Unterschied zwischen ihnen liegt nicht in der Technik, sondern darin, welche Daten sie voraussetzen — und ob Sie die haben.

Dieser Artikel geht die sechs durch. Zu jedem steht, was er braucht und wann er sich nicht lohnt. Die zweite Angabe ist die nützlichere.

Welche KI-Use-Cases gibt es im Maschinenbau?

Die Spalte ganz rechts entscheidet öfter über den Projekterfolg als die beiden davor. Wer sie überspringt, baut zuverlässig das teure Drittel unserer fünf häufigsten Fehler in KI-Projekten nach.

1. Predictive Maintenance

Ein Modell erkennt an Sensorwerten, dass sich ein Ausfall anbahnt, und meldet ihn, bevor die Maschine steht. Der Reiz ist offensichtlich: ungeplanter Stillstand ist im Maschinenbau die teuerste Störungsart.

Was es voraussetzt: Sensordaten über einen Zeitraum, der mehrere echte Ausfälle enthält, und eine Instandhaltungshistorie, die diese Ausfälle datiert und benennt. Ein Modell lernt aus Beispielen. Wer drei dokumentierte Lagerschäden hat, hat keine Lerngrundlage.

Wann es sich nicht lohnt: Wenn Ausfälle selten sind — genau dann fehlen die Beispiele. Und wenn die Instandhaltung im Kopf der Techniker stattfindet statt im System. Dann ist das erste Projekt nicht KI, sondern eine belastbare Erfassung.

Die Alternative, die oft übersehen wird: Anomalieerkennung. Sie meldet Abweichungen vom Normalbetrieb, ohne den konkreten Schaden vorherzusagen. Sie braucht keine Ausfallhistorie, nur einen sauberen Normalzustand — und ist damit für viele Betriebe der realistischere Einstieg.

2. Visuelle Qualitätskontrolle

Eine Kamera prüft Bauteile auf Oberflächenfehler, Maßabweichungen oder Vollständigkeit. Das ist der am längsten etablierte Use-Case in dieser Liste und technisch der ausgereifteste.

Was es voraussetzt: Bilder von Gutteilen und von jedem Fehlerbild, das erkannt werden soll — in der Größenordnung einiger hundert je Klasse. Vor allem aber: reproduzierbare Aufnahmebedingungen. Beleuchtung, Abstand und Winkel müssen konstant sein.

Wann es sich nicht lohnt: Bei ständig wechselnden Fehlerbildern in kleinen Losgrößen. Und wenn die Prüfung nicht in eine feste Station passt, weil das Teil zu groß oder die Prüfstelle zu variabel ist. Die Mechanik drumherum ist häufig aufwendiger als das Modell.

3. Produktionsplanung und Disposition

Reihenfolgen bilden, Rüstzeiten minimieren, Kapazitäten gegen Termine rechnen. Klassische Optimierung, in der KI dort hilft, wo die Regeln zu verwickelt für eine Formel sind.

Was es voraussetzt: Auftragsdaten, Kapazitäten und realistische Rüstzeiten aus dem ERP. Das Wort „realistisch“ trägt hier das Gewicht. Rüstzeitstammdaten, die seit Jahren nicht angefasst wurden, erzeugen einen Plan, dem niemand folgt.

Wann es sich nicht lohnt: Wenn die tatsächliche Planung von Zurufen, Eilaufträgen und Sonderabsprachen bestimmt wird. Ein optimierter Plan, den die Meisterebene morgens umwirft, verbessert nichts. Dann ist das Problem organisatorisch, nicht rechnerisch.

4. Angebots- und Kalkulationsautomatisierung

Aus Anfrage und Zeichnung eine Vorkalkulation ableiten, gestützt auf vergleichbare vergangene Aufträge. Der stillste Use-Case der Liste und häufig der mit dem besten Verhältnis von Aufwand zu Wirkung.

Was es voraussetzt: Historische Angebote — und, wichtiger, deren Nachkalkulation. Ohne den Abgleich zwischen kalkuliert und tatsächlich lernt das System, Ihre alten Fehleinschätzungen zu reproduzieren.

Wann es sich nicht lohnt: Bei echten Unikaten ohne Wiederholteile. Sobald aber ein Baukasten oder eine Teilefamilie existiert, greift der Use-Case schnell.

5. Service- und Ersatzteilanfragen

Eingehende Serviceanfragen vorqualifizieren, das passende Ersatzteil zur Maschinennummer finden, wiederkehrende Fragen direkt beantworten. Der niedrigschwelligste Einstieg in dieser Liste.

Was es voraussetzt: Eine Ticket-Historie, einen gepflegten Ersatzteilkatalog und die Verbindung zwischen Maschinennummer und verbauter Konfiguration. Die letzte Verknüpfung fehlt öfter, als man denkt, und ist der eigentliche Aufwandstreiber.

Wann es sich nicht lohnt: Bei kleinem Anfragevolumen. Wenn zwei Personen den Service nebenbei erledigen, spart die Automatisierung weniger, als ihre Pflege kostet.

6. Technische Dokumentation erzeugen

Betriebsanleitungen, Wartungspläne, Änderungsbeschreibungen und Übersetzungen aus vorhandenen Bausteinen erzeugen statt jedes Mal neu schreiben. Relevant nicht nur wegen des Aufwands: Die Maschinenverordnung (EU) 2023/1230 löst ab Januar 2027 die bisherige Maschinenrichtlinie ab und erlaubt ausdrücklich die digitale Bereitstellung der Betriebsanleitung. Wer seine Dokumentation ohnehin anfassen muss, kann den Prozess gleich mit angehen.

Was es voraussetzt: Bestehende Anleitungen als Muster, eine halbwegs konsistente Terminologie und eine Baukastenstruktur, aus der sich Varianten ableiten lassen.

Wann es sich nicht lohnt: Wenn jede Maschine dokumentarisch bei null beginnt. Dann fehlt das Wiederverwendbare, und der Prüfaufwand frisst den Zeitgewinn.

Welcher Use-Case lohnt sich zuerst?

Nicht der mit dem größten Hebel, sondern der mit der besten Datenlage. Diese Reihenfolge hat sich bewährt:

1. Erst der Use-Case, dessen Daten schon strukturiert vorliegen — meist Angebotskalkulation oder Serviceanfragen. Er liefert früh ein Ergebnis, an dem sich intern zeigen lässt, dass die Sache trägt.
2. Dann der mit dem größten Hebel — oft Predictive Maintenance oder Produktionsplanung. Beide brauchen Vorlauf in der Datenerfassung, der parallel zum ersten Projekt laufen kann.
3. Datenerfassung nachziehen, nicht vorziehen. Wer mit einem zweijährigen Datenprojekt beginnt, verliert die Rückendeckung, bevor das erste Ergebnis da ist.

Was das kostet, haben wir in Was kostet ein KI-Projekt? mit Spannen und einer Beispielrechnung aufgeschlüsselt. Die Kurzfassung: Der Aufwand steckt selten im Modell, sondern in der Datenaufbereitung — in der Praxis regelmäßig 40 bis 60 Prozent des Projekts.

Was ist mit Konstruktion und Normensuche?

Das Durchsuchen bestehender Konstruktionsunterlagen, Normen und Projektakten ist ein eigener Use-Case — und ein sehr realer. Er kommt in diesem Artikel bewusst nicht vor.

Der Grund ist eine saubere Trennung: Wer Dokumentation und Normen durchsuchen und belegen will, sucht ein Werkzeug, kein Projekt. Dafür gibt es KoAssist — einen Assistenten, der aus den eigenen Unterlagen antwortet und dabei Datei und Seite mitliefert. Das ist im Engineering keine Bequemlichkeit, sondern die Bedingung dafür, dass eine Antwort überhaupt verwendbar ist.

Dokumentation erzeugen ist dagegen eine Entwicklungsleistung und steht deshalb oben als Use-Case 6.

Wie startet ein Pilotprojekt?

Vier Schritte, die sich im Mittelstand bewährt haben:

1. Use-Case auswählen — nach Datenlage, nicht nach Begeisterung. Die Tabelle oben ist dafür gedacht.
2. Datenprüfung vor der Entwicklung. Zwei bis drei Tage, in denen jemand die Daten tatsächlich öffnet. Diese Prüfung hat schon Projekte verhindert, und das war jedes Mal die günstigere Variante.
3. Abgegrenzter Proof of Concept. Ein Use-Case, eine Maschine oder eine Produktfamilie, ein messbares Kriterium, das vorher festgelegt wird.
4. Erst danach über Integration und Betrieb entscheiden. Was in der Produktion läuft, muss gewartet, überwacht und aktualisiert werden. Diese Kosten gehören von Anfang an in die Rechnung, nicht in die Nachbetrachtung.

Wenn Sie einen konkreten Use-Case im Kopf haben und wissen wollen, ob Ihre Datenlage trägt: Wir sehen uns das in einem kostenlosen Erstgespräch an. Auch dann, wenn die ehrliche Antwort „noch nicht“ lautet.