Die fünf Eigenschaften jeder Engineering-Fähigkeit

VonThomas Luft

Worum es hier geht

  • Eine KI-Fähigkeit, die in Engineering-Workflows produktiv sein soll, braucht fünf Eigenschaften: Selbstbeschreibung mit Methoden-Kontext, standardisierte Schnittstellen mit Domain-Schema, Gedächtnis mit FMEA-Versionierung, Orchestrierbarkeit aus dem Workflow, Rückkopplungsschleife aus Reviews.
  • Ein Custom GPT hat meistens zwei oder drei davon. Das macht ihn brauchbar für Einzelaufgaben, aber nicht zum Bestandteil eines Engineering-Betriebssystems.
  • Die Engineering-Variante ist eine Adaption für eine Branche, in der Audits, Standards und Domain-Strukturen die Architektur mitbestimmen.

Warum „funktioniert“ als Maßstab nicht reicht

Ein Custom GPT, der eine Strukturanalyse vorschlägt, funktioniert. Er liefert Text auf eine Frage. Wenn er aber nicht weiß, was er beim letzten Mal gesagt hat, wenn er seinen Output nur als Chat-Text ausgibt statt als FMEA-Struktur, wenn er nicht aus einer anderen Fähigkeit aufgerufen werden kann und wenn Feedback aus den Reviews nicht zurück in sein Verhalten fließt — dann ist er keine Komponente eines Systems, sondern eine Insellösung in einem Tab.

Funktionieren ist nicht genug. Die fünf Eigenschaften unten sind das Maß, ob eine Fähigkeit produktiv in einem Engineering-Betriebssystem leben kann.

Eigenschaft 1: Selbstbeschreibung mit Methoden-Kontext

Eine Fähigkeit erklärt selbst, was sie tut und welche Methodik sie kennt. Bei einer FMEA-Strukturanalyse-Fähigkeit heißt das: Welchen Standard kennt sie (AIAG/VDA 2019, ISO 26262, MIL-STD-1629)? Welche Eingabe erwartet sie? Welche Ausgabe liefert sie? Was tut sie ausdrücklich nicht?

Im allgemeinen B2B-Kontext geht es um „erklärt sich selbst, damit der Nutzer es findet“. Im Engineering geht es zusätzlich um Methoden-Treue. Eine Fähigkeit, die nicht klar sagt, gegen welche Methodik sie arbeitet, kann in einem Audit zum Risiko werden.

In meinem Aufbau hängt die Selbstbeschreibung an jeder n8n-Workflow als Sticky Note und als JSON-Block in den Workflow-Eigenschaften. Wer den Workflow öffnet, sieht in fünf Sekunden, was er tut und gegen welche Regeln. Wer per API anfragt, bekommt dieselbe Beschreibung maschinenlesbar zurück.

Eigenschaft 2: Standardisierte Schnittstellen mit Domain-Schema

Eine Engineering-Fähigkeit nimmt strukturierten Input und gibt strukturierten Output:

  • Eingabe: JSON mit FMEA-Strukturanalyse — System-Elemente, Hierarchie, Versionsstand
  • Ausgabe: JSON mit Vorschlägen, jeweils mit Verweis auf die Eingabe-Version
  • Trigger: drei Standard-Wege — Chat, Zeitplan, SubWorkflow-Aufruf
  • Fehler-Verhalten: definiert, was bei ungültiger Eingabe passiert

Ein Custom GPT, der eine Strukturanalyse als freien Text zurückgibt, erfüllt diese Eigenschaft nicht. Der Text ist menschlich lesbar, aber maschinell weiterverarbeiten heißt: parsen, Strukturen erraten, Fehler abfangen. Genau das macht den Tool-Zoo aus, vor dem Spoke 1 warnt.

In der Praxis heißt diese Eigenschaft: die Fähigkeit kennt das Datenmodell eurer FMEA-Software (APIS IQ, Plato e1ns, andere) und gibt Ergebnisse so zurück, dass sie ohne Übersetzungsschritt landen können.

Eigenschaft 3: Gedächtnis mit FMEA-Versionierung

Eine Fähigkeit speichert ihren Zustand zwischen Aufrufen. Im allgemeinen B2B-Kontext heißt das: sie merkt sich, was der Nutzer zuletzt gefragt hat. Im Engineering heißt es zusätzlich: sie kennt frühere Zustände der FMEA und kann erklären, was sich wann geändert hat.

Konkret in der FMEA-Praxis:

  • Welche System-Elemente waren in der vorigen Sitzung definiert?
  • Welcher AP-Wert galt vor der letzten Maßnahme?
  • Welcher Vorschlag stammt von welcher KI mit welchem Prompt?

Ohne diese Versions-Geschichte ist eine Fähigkeit für ernsthafte Engineering-Arbeit nicht zu gebrauchen. Spätestens im Review fragt jemand „warum wurde die AP von B nach C geändert?“ — die Antwort muss nachvollziehbar vorliegen.

In meinem Setup übernimmt PostgreSQL die Versionierung. Jeder Vorschlag landet als Datensatz mit Zeitstempel, Quell-KI und Eingabe-Kontext. Das ist nicht spezifischer Code, sondern Datenmodell-Disziplin.

Eigenschaft 4: Orchestrierbarkeit aus dem Engineering-Workflow

Eine Fähigkeit ist nicht nur per Chat erreichbar, sondern auch aus anderen Fähigkeiten heraus aufrufbar. Sie ist eine Komponente, nicht eine Anwendung.

In der FMEA-Praxis sieht das so aus:

  • Eine Strukturanalyse-Fähigkeit liefert System-Elemente
  • Eine Funktionsanalyse-Fähigkeit wird danach automatisch aufgerufen, mit den System-Elementen als Eingabe
  • Eine Plausibilitäts-Fähigkeit prüft im Hintergrund, ob beide zueinander passen
  • Alles ohne, dass ein Mensch dazwischen klickt

Ein Custom GPT erfüllt diese Eigenschaft nicht — er ist nur per Chat erreichbar. Ein n8n-Workflow erfüllt sie, wenn er als SubWorkflow aus anderen Workflows aufgerufen werden kann. Das ist das Kern-Merkmal eines Systems: die Teile arbeiten miteinander, nicht nebeneinander.

Eigenschaft 5: Rückkopplungsschleife aus Reviews

Eine Fähigkeit lernt aus dem, was hinterher passiert. Im Engineering heißt das: Wenn ein FMEA-Team einen KI-Vorschlag ablehnt, korrigiert oder annimmt, fließt diese Entscheidung zurück in das System.

Konkret:

  • Das System speichert, welche Vorschläge angenommen, abgelehnt oder geändert wurden
  • Es liest die Korrekturen und passt zukünftige Vorschläge an
  • Es kennt die Begründungen, nicht nur die Entscheidungen

Diese Rückkopplungsschleife ist es, die aus einer einmaligen KI-Beratung ein lernendes System macht. In meinem Setup landet das Feedback in einer eigenen Tabelle, die von jeder Fähigkeit gelesen werden kann.

Ohne diese Schleife wiederholt eine KI bei jedem neuen Bauteil dieselben Fehler. Mit dieser Schleife wird sie in wenigen Bauteil-Zyklen besser, als ein Custom GPT je werden kann.

Schlenther, Engineering und der Unterschied

Den Begriff KI-Betriebssystem hat Felix Schlenther im allgemeinen B2B-Kontext geprägt. Die fünf Eigenschaften, wie ich sie oben beschreibe, sind eine Engineering-Adaption. Im klassischen Office-Setting reichen die Schlenther-Eigenschaften in ihrer generischen Form. Im Engineering sind sie ohne die Domain-Anker — Methodik, Domain-Schema, FMEA-Versionierung, Workflow-Orchestrierung, Review-Rückkopplung — nicht produktiv.

Es ist kein Widerspruch. Es ist eine Übersetzung in eine Branche, in der Audits, Standards und strukturierte Domain-Daten die Architektur mitbestimmen.

Was das in eurer Praxis ändert

Vor der nächsten Tool-Auswahl: Geht die fünf Eigenschaften durch. Eine Fähigkeit, die zwei oder drei erfüllt, ist ein Custom GPT — nützlich für Einzelaufgaben, aber kein Bestandteil eines Systems. Eine Fähigkeit, die alle fünf erfüllt, ist ein Teil eures Engineering-Betriebssystems.

Wer auf meinGPT* als Frontend setzt und n8n als Skills-Schicht im Hintergrund, hat die Architektur, in der diese Eigenschaften überhaupt entstehen können. Sie sind nicht eingebaut — sie sind das, was beim Aufbau jeder einzelnen Fähigkeit konzipiert wird.

Nächste Schritte

Hinweis: Mit * gekennzeichnete Links sind Werbung (Affiliate-Links).

Thomas Luft ist PCC-zertifizierter FMEA-Experte und AGILean Coach. Er berät Engineering-Unternehmen beim Aufbau KI-gestützter Prozesse. Kontakt und weitere Infos: fmea-ki.de.

Ähnliche Beiträge