„KI in Embedded Systems — Wie neuronale Netze bei der Motorregelung unterstützen“
MANAGEMENT SUMMARY1
Der Artikel ist ingenieurtechnisch solide und beschreibt mit der hybriden Architektur (klassische Regler als deterministische Basis, KI-Komponente für adaptive Teilaufgaben, Offline-Training, reine On-Device-Inferenz, Fallback-Konzepte) exakt jene Entwurfsmuster, die auch regulatorisch der richtige Weg sind. Auffällig ist jedoch: Der Beitrag erwähnt mit keinem Wort den regulatorischen Rahmen, in den genau dieses Produkt ab 2027/2028 fällt. Ein Stellantrieb mit RL-Policy in der Motorregelung berührt unmittelbar die Maschinenverordnung (EU) 2023/1230 (gilt ab 20.01.2027 — also vor Markteinführungen der beschriebenen Lösung), potenziell das Hochrisiko-Regime der KI-Verordnung (EU) 2024/1689 (für eingebettete Systeme nach Digital Omnibus ab 02.08.2028) sowie den Cyber Resilience Act (Meldepflichten ab 11.09.2026). Mehrere Kernaussagen des Artikels — „das Gesamtsystem bleibt erklärbar“, Robustheit sei „implizit in den Trainingsdaten enthalten“, Fallback-Regler genügten als Sicherheitskonzept — sind aus Compliance-Sicht ungesichert bis überzeichnet und sollten thematisiert werden. Insgesamt: gutes Engineering-Playbook, aber ohne den Governance-Teil, der ab 2027 über den Marktzugang entscheidet.
1. Was der Artikel beschreibt — und was er richtig macht
Burger Engineering und das Spices Lab der TH Nürnberg untersuchen den Einsatz neuronaler Netze und Reinforcement Learning zur Unterstützung der Motorregelung auf Embedded Controllern (32-Bit-MCUs, teils mit NPU) am Beispiel eines mechatronischen Stellantriebaktuators (DC/BLDC). Die klassische Kaskade (Strom-, Drehzahl-, Positionsregelung) bleibt bestehen; die KI-Komponente übernimmt Teilaufgaben wie die adaptive Anpassung von Reglerparametern, die Kompensation nichtlinearer Effekte oder zusätzliche Stellgrößen bei Laständerungen. Training erfolgt offline (Real-to-Sim), auf dem Zielsystem läuft ausschließlich die quantisierte Inferenz (TinyML, INT8, Festpunktarithmetik) mit Inferenzzeiten im Millisekundenbereich. Positiv hervorzuheben: Die Architekturentscheidungen — kein Black-Box-Vollregler, deterministische klassische Basisfunktionen, KI nur in definierten Betriebsbereichen, klassischer Regler als Fallback, Offline-Training statt Online-Lernen im Feld — entsprechen genau den Mustern, die Normungsgremien (u. a. ISO/IEC TR 5469 zu KI und funktionaler Sicherheit) und die Maschinenverordnung für lernfähige Systeme nahelegen. Auch das Bewusstsein für Datenqualität und einen reproduzierbaren Workflow (Datenerfassung → Training → Validierung → Sim-to-Real → Deployment) ist vorhanden. Die technische Basis für Compliance ist also gelegt — sie wird nur nicht als solche erkannt und benannt.
2. Zentrale Leerstelle: Der EU AI Act kommt nicht vor
2.1 Die beschriebene Lösung ist ein KI-System im Sinne der KI-VO
Eine per Reinforcement Learning trainierte Policy bzw. ein neuronales Netz, das aus Eingaben Stellgrößen oder Parameteranpassungen ableitet, erfüllt die Definition des KI-Systems nach Art. 3 Nr. 1 KI-VO (maschinenbasiertes System, das aus Eingaben Ausgaben wie Empfehlungen oder Entscheidungen ableitet und dabei mit unterschiedlichem Grad an Autonomie operiert). Dass die Inferenz eingebettet auf einer MCU läuft, ändert daran nichts — die KI-VO ist technologie- und plattformneutral.
2.2 Die Hochrisiko-Frage entscheidet sich an der Sicherheitsbauteil-Eigenschaft Nach Art. 6 Abs. 1 KI-VO ist ein KI-System hochriskant, wenn es (a) Sicherheitsbauteil eines Produkts ist, das unter die Harmonisierungsrechtsvorschriften des Anhangs I fällt — dazu zählt die Maschinenverordnung —, und (b) dieses Produkt einer Konformitätsbewertung durch Dritte unterliegt. Genau hier liegt die kritische Weiche für den beschriebenen Anwendungsfall: Übernimmt die KI-Komponente in einem Stellantrieb sicherheitsrelevante Funktionen (etwa Momentenbegrenzung, Kollisionsverhalten, sichere Positionierung in Handhabungssystemen mit Personenkontakt), greift die Verzahnung MVO ↔ KI-VO. Wirkt sie dagegen ausschließlich auf Performance-Größen (Energieeffizienz, Einschwingverhalten) ohne Sicherheitsfunktion, bleibt sie außerhalb des Hochrisiko-Regimes. Der Artikel lässt diese Abgrenzung vollständig offen — beschreibt aber mit „Generierung zusätzlicher Stellgrößen bei Laständerungen“ eine Funktion, die je nach Einsatzszenario durchaus sicherheitsrelevant sein kann. ⚠ Ungeklärte Rechtsfrage: Entlastet der Fallback-Regler? Der Artikel behandelt den klassischen Regler als Fallback implizit als hinreichendes Sicherheitskonzept. Das Fraunhofer IESE weist jedoch darauf hin, dass ungeklärt ist, ob ein KI-System für eine sicherheitskritische Funktion seine Sicherheitsbauteil-Eigenschaft verliert, wenn redundante Maßnahmen bei Ausfall oder Fehler „einspringen“. Wer die Hochrisiko-Einstufung allein über die Fallback-Architektur wegargumentiert, bewegt sich auf ungesichertem Terrain — die Einstufungsentscheidung ist zu dokumentieren und sollte konservativ getroffen werden.
2.3 Neue Zeitachse nach dem Digital Omnibus (beschlossen Juni 2026) Der Artikel erschien am 01.07.2026 — zwei Tage nach der finalen Ratszustimmung zum Digital Omnibus (29.06.2026; EP-Billigung 16.06.2026) — und hätte die neue Planungsgrundlage bereits reflektieren können. Relevant für eingebettete KI: Die Hochrisiko-Pflichten für KI-Systeme in Produkten nach Anhang I (u. a. Maschinen) gelten nun ab 02.08.2028 (statt 02.08.2027); für eigenständige Anhang-III-Systeme ab 02.12.2027. Wichtig: Verschoben wurden nur die Fristen — die materiellen Anforderungen der Art. 9–15 KI-VO (Risikomanagement, Daten-Governance, technische Dokumentation, Logging, menschliche Aufsicht, Genauigkeit/Robustheit/Cybersicherheit) bleiben unverändert. Zudem schafft der Omnibus einen Mechanismus, mit dem die Kommission Überschneidungen zwischen KI-VO und sektoralem Produktrecht — ausdrücklich auch der Maschinenverordnung — per Durchführungsrechtsakt auflösen kann. Die KI-Kompetenzpflicht (Art. 4) gilt bereits seit 02.02.2025 und betrifft auch Entwicklungsteams wie das beschriebene.
3. Maschinenverordnung 2023/1230: Die eigentlich nächstliegende Baustelle
Noch auffälliger als die fehlende KI-VO-Referenz ist das Schweigen zur Maschinenverordnung — denn sie gilt ab 20.01.2027 und damit vor jeder realistischen Serieneinführung der beschriebenen Lösung. Für den Artikel-Anwendungsfall sind vier Punkte einschlägig: • Software als Sicherheitsbauteil: Die MVO erweitert den Sicherheitsbauteil-Begriff ausdrücklich auf Software und digitale Logikbausteine. Eine KI-Komponente, die eine Sicherheitsfunktion wahrnimmt, unterliegt damit der Konformitätsbewertungspflicht. • Selbstentwickelndes Verhalten → Benannte Stelle: Sicherheitsbauteile und Maschinen mit vollständig oder teilweise selbstentwickelndem Verhalten unter Verwendung maschinellen Lernens, die Sicherheitsfunktionen gewährleisten, fallen unter Anhang I Teil A der MVO — mit verpflichtender Einbindung einer notifizierten Stelle. Diese Drittzertifizierung ist zugleich der Trigger für die Hochrisiko-Einstufung nach Art. 6 Abs. 1 KI-VO (siehe Abschnitt 2.2). • Lebenszyklus-Risikobeurteilung: Bei Maschinen mit sich entwickelndem Verhalten müssen auch Risiken einbezogen werden, die nach dem Inverkehrbringen auftreten können. Der Artikel adressiert Alterung und Verschleiß nur als Trainingsdaten-Thema — nicht als fortlaufende Risikobeurteilungspflicht. • Modell-Updates als „wesentliche Veränderung“: Die MVO erweitert den Begriff der wesentlichen Veränderung auf digitale Eingriffe wie Software-Updates. Ein nachtrainiertes und neu deploytes Modell kann eine erneute Konformitätsbewertung auslösen — und wer nachträglich ein KI-Modul in eine Bestandsmaschine integriert, wird selbst zum Hersteller. Für das im Artikel beworbene Geschäftsmodell (Reduktion von Engineering-Aufwand durch datengetriebene Adaption über Varianten und Serienanpassungen hinweg) ist das ein zentraler, unerwähnter Kostenfaktor.
-
ISO/IEC 42001: Workflow ist kein Managementsystem Der Artikel betont zu Recht, KI müsse vom „experimentellen Element“ zum „reproduzierbaren Ingenieurwerkzeug“ werden, und beschreibt dafür einen technischen Workflow. Aus Sicht der ISO/IEC 42001 (AI Management System, publiziert Ende 2023) fehlt jedoch die organisatorische Hälfte: • Governance und Rollen: Wer verantwortet Modellfreigaben, wer entscheidet über Betriebsbereichsgrenzen der KI, wer überwacht das Verhalten im Feld? Ein AIMS verlangt definierte Verantwortlichkeiten über den gesamten Lebenszyklus — der Artikel bleibt beim Entwicklungsprozess stehen. • KI-Risikomanagement und Impact Assessment: ISO/IEC 42001 (i. V. m. ISO/IEC 23894 und ISO/IEC 42005) fordert systematische Risiko- und Auswirkungsbewertungen je System — methodisch anschlussfähig an Art. 9 KI-VO. Im Artikel existiert Risiko nur als Regelungstechnik-Begriff (Stabilität), nicht als dokumentierter Managementprozess. • Daten-Governance statt Datenqualitäts-Appell: „Trainingsdaten in hoher Qualität“ ist als Anforderung richtig, bleibt aber ein Appell. Art. 10 KI-VO macht daraus für Hochrisiko-Systeme eine dokumentationspflichtige Rechtspflicht (Repräsentativität, Fehlerfreiheit soweit möglich, Abdeckung der Einsatzbedingungen). Die Artikel-Behauptung, Robustheit gegenüber Alterung, Verschleiß und thermischen Effekten sei „implizit in den Trainingsdaten enthalten“, verkehrt dabei die Logik: Sie ist es nur, wenn diese Zustände nachweislich und systematisch in den Daten abgedeckt wurden — ein impliziter Robustheitsanspruch ist das Gegenteil von Daten-Governance. • Monitoring nach Deployment und MLOps: Sim-to-Real-Gap, Distributional Shift durch Anlagenalterung und Modell-Versionierung verlangen kontinuierliche Überwachung, Logging (Art. 12 KI-VO) und definierte Retraining-Prozesse. Der Artikel endet konzeptionell beim Deployment.
-
Funktionale Sicherheit und Erklärbarkeit: Zwei überzeichnete Claims
Claim 1 — „Dadurch bleibt das Gesamtsystem erklärbar und kontrollierbar“: Die hybride Architektur begrenzt den Einfluss der KI-Komponente, macht die trainierte Policy selbst aber nicht erklärbar. Für die Nachweisführung nach IEC 61508 / ISO 13849 / IEC 62061 sind datengetriebene Komponenten weiterhin nicht regulär qualifizierbar; ISO/IEC TR 5469 beschreibt genau deshalb Architekturen, in denen KI außerhalb des Sicherheitspfads gehalten oder durch überwachende deterministische Instanzen eingehegt wird. Die korrekte Aussage wäre: Das Sicherheitsverhalten bleibt durch die klassische Architektur nachweisbar — die KI-Komponente bleibt eine Black Box, deren Einfluss begrenzt wird. Für Transparenzpflichten (Art. 13 KI-VO) und die technische Dokumentation (Art. 11, Anhang IV) ist diese Differenzierung wesentlich.
Claim 2 — Fallback plus definierte Betriebsbereiche als Sicherheitskonzept: Richtig als Muster, unvollständig als Nachweis. Offen bleiben: Wie wird der Austritt aus dem validierten Betriebsbereich detektiert (Out-of-Distribution-Erkennung)? Wie wird ein „stiller“ Fehlbeitrag der KI erkannt, der die Regelgüte degradiert, ohne Grenzwerte zu verletzen? Wie wird die Umschaltung auf den Fallback selbst sicher gestaltet (stoßfreies Umschalten unter Last)? Und: Adversarial Robustness und Manipulationsschutz des Modells (Art. 15 KI-VO, MVO Anhang III Ziff. 1.1.9 — Schutz sicherheitsrelevanter Software gegen Korrumpierung) werden nicht erwähnt.
- Flankierende Rechtsakte: CRA und neue Produkthaftung • Cyber Resilience Act (VO (EU) 2024/2847): Ein Stellantrieb mit vernetzbarer Steuerung ist ein Produkt mit digitalen Elementen. Ab 11.09.2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen, ab 11.12.2027 die Vollanwendung inkl. SBOM — die dann auch Inferenzbibliotheken, Modellartefakte und den TinyML-Toolchain-Output umfassen sollte. Firmware-Updates mit neuen Modellen berühren zugleich CRA-Updateprozesse und MVO-Veränderungsfragen (Abschnitt 3).
• Neue Produkthaftungsrichtlinie (EU) 2024/2853: Software — einschließlich KI — ist künftig ausdrücklich Produkt im haftungsrechtlichen Sinn; die Richtlinie ist bis 09.12.2026 in nationales Recht umzusetzen und bringt Beweislast-Erleichterungen für Geschädigte. Ein durch unvollständige Trainingsdaten „instabiles oder nicht reproduzierbares Verhalten“ (so der Artikel selbst über die Folge schlechter Daten) wird damit unmittelbar haftungsrelevant. • Österreich-Bezug: Für Anbieter am österreichischen Markt sind ergänzend die nationalen Marktüberwachungs- und Meldestrukturen relevant (KI-Marktüberwachung bei der RTR, CSIRT-Meldeweg über cert.at im CRA-Kontext); Betreiberseitig können je nach Einsatzumfeld zusätzlich arbeitsverfassungsrechtliche Fragen (ArbVG §§ 96/96a bei personenbezogenen Kontrollsystemen) auftreten — für reine Motorregelung regelmäßig nicht, bei übergreifenden Condition-Monitoring-Daten mit Personalbezug aber prüfenswert.
-
Befundmatrix Thema / Artikel-Aussage Regulatorischer Befund Bewertung & Handlungsbedarf Regulatorischer Rahmen wird nicht erwähnt KI-VO, MVO 2023/1230, CRA und ProdHaftRL 2024/2853 greifen sämtlich vor bzw. mit Markteinführung solcher Lösungen (2027/2028) Zentrale Lücke des Artikels. Compliance-Betrachtung gehört in jede seriöse Darstellung von KI in Antriebstechnik „KI unterstützt nur, klassische Regler bleiben“ — implizit: keine Regulierung Sicherheitsbauteil-Eigenschaft hängt von der Funktion ab, nicht vom Architekturmuster; Fallback-Entlastung ist rechtlich ungeklärt (Fraunhofer IESE) Einstufungsentscheidung je Einsatzszenario dokumentieren; bei Sicherheitsbezug konservativ Hochrisiko annehmen Adaptive Anpassung von Reglerparametern zur Laufzeit MVO Anhang I Teil A erfasst selbstentwickelndes Verhalten mit Sicherheitsfunktion → notifizierte Stelle; KI-VO-Hochrisiko folgt nach Abgrenzung „frozen inference“ vs. Online-Adaption präzisieren — regulatorisch fundamental unterschiedlich „Gesamtsystem bleibt erklärbar und kontrollierbar“ Policy bleibt Black Box; IEC 61508/ISO 13849 bieten keine ML-Nachweisführung; ISO/IEC TR 5469 als Brücke Claim präzisieren: nachweisbares Sicherheitsverhalten ≠ erklärbare KI-Komponente Robustheit „implizit in Trainingsdaten enthalten“ Art. 10 KI-VO: Daten-Governance mit nachweisbarer Abdeckung der Betriebszustände; implizit genügt nicht Systematische Datenanforderungsdefinition, Coverage-Nachweis, Dokumentation Workflow bis Deployment beschrieben, danach Ende Art. 12 KI-VO (Logging), Art. 72 (Post-Market-Monitoring), MVO-Lebenszyklus-Risikobeurteilung, ISO/IEC 42001-Betriebsphase Monitoring-, Logging- und Retraining-Governance ergänzen (MLOps) Modell-Updates / Serienanpassungen als Effizienzvorteil MVO: digitale Eingriffe können wesentliche Veränderung sein; CRA-Updateprozesse; ggf. erneute Konformitätsbewertung Update-Strategie mit Konformitäts-Impact-Bewertung je Modellrelease Cybersicherheit nicht thematisiert Art. 15 KI-VO, MVO Anhang III 1.1.9 (Schutz vor Korrumpierung), CRA ab 09/2026 bzw. 12/2027 Modell- und Firmware-Integrität (Signierung), Manipulationsschutz, SBOM inkl. ML-Artefakte Fristen/Digital Omnibus fehlen (Artikel vom 01.07.2026) Omnibus final: Rat 29.06.2026; eingebettete Hochrisiko-KI ab 02.08.2028, MVO dennoch ab 20.01.2027 MVO ist der zeitkritische Pfad — nicht die KI-VO. Diese Priorisierung sollte kommuniziert werden
-
Empfehlung: Welche Themen thematisiert werden sollten Für eine Fortführung der Diskussion — sei es als Erwiderung, Fachbeitrag oder Beratungsangebot — bieten sich folgende Themen an, die der Artikel offenlässt: • Die Einstufungsfrage als Entwurfsentscheidung: Ob eine KI-Komponente Sicherheitsbauteil wird, lässt sich architektonisch steuern (KI strikt außerhalb des Sicherheitspfads, deterministische Limiter/Monitore davor). Das ist die wirtschaftlich wichtigste Weichenstellung des gesamten Vorhabens — und ein exzellentes Beratungs- und Content-Thema. • Der Zeitpfad MVO vor KI-VO: 20.01.2027 (MVO) kommt vor 02.08.2028 (eingebettete Hochrisiko-KI). Wer heute entwickelt, muss zuerst maschinenrechtlich denken. • Von TinyML-Workflow zu auditierbarem Lifecycle: Der beschriebene Workflow ist die technische Vorstufe eines ISO/IEC-42001-konformen Lebenszyklus — die Lücken (Rollen, Risikoprozess, Daten-Governance, Post-Market-Monitoring) sind konkret benennbar und schließbar. • Nachweisführung für hybride Architekturen: ISO/IEC TR 5469, Safety-Envelope-Konzepte, OOD-Detektion und stoßfreie Fallback-Umschaltung als Stand der Technik gegenüber notifizierten Stellen. • Update- und Haftungsökonomie: Modellpflege über Produktlebenszyklen (wesentliche Veränderung, CRA-Prozesse, ProdHaftRL-Beweislast) als Total-Cost-Betrachtung — das relativiert die im Artikel beworbene Engineering-Aufwandsreduktion ehrlich.
Quellen [1] Klenke, J.: „KI in Embedded Systems — Wie neuronale Netze bei der Motorregelung unterstützen“, Maschinenmarkt (Vogel), 01.07.2026 — maschinenmarkt.vogel.de/wie-neuronale-netze-bei-der-motorregelung-unterstuetzen-a-cb21a13d43236d91f1c91814d0eef5e4/
[2] Verordnung (EU) 2024/1689 (KI-Verordnung), insb. Art. 3, 4, 6 Abs. 1, 9–15, 72 — eur-lex.europa.eu/eli/reg/2024/1689/oj; Art.-6-Kommentierung: ai-act-law.eu/de/artikel/6/ bzw. artificialintelligenceact.eu/de/article/6/
[3] Digital Omnibus on AI (Omnibus VII): EP-Billigung 16.06.2026, Ratsbeschluss 29.06.2026; neue Fristen 02.12.2027 (Anhang III) / 02.08.2028 (Anhang I, eingebettete Systeme); Überschneidungs-Mechanismus zur MVO — E+H Rechtsanwälte (eh.at), Heuking (heuking.de), activeMind.legal, t3n.de, borncity.com (Juni/Juli 2026)
[4] Verordnung (EU) 2023/1230 (Maschinenverordnung), gültig ab 20.01.2027: Software als Sicherheitsbauteil, Anhang I Teil A (selbstentwickelndes Verhalten mit Sicherheitsfunktion), Anhang III Ziff. 1.1.9 (Schutz vor Korrumpierung), wesentliche Veränderung durch Software — eur-lex.europa.eu/eli/reg/2023/1230/oj; Praxisaufbereitungen: Ebner Stolz (ebnerstolz.de), WEKA (weka.de), Conrad-Ratgeber, maschinenverordnung-2027.eu
[5] TÜV SÜD: „EU AI Act: KI-Verordnung für Maschinen“ — kombinierte Konformitätsbewertung MVO/KI-VO — tuvsud.com/de-de/dienstleistungen/produktpruefung-und-produktzertifizierung/eu-ai-act
[6] Ferner Alsdorf: „EU-Maschinenverordnung: Produktsicherheit & KI in Maschinen“ — Verzahnung Drittzertifizierung MVO → Hochrisiko-Einstufung KI-VO, Art. 9–15 — ferner-alsdorf.de/verordnung-ueber-sichere-maschinenprodukte/
[7] Fraunhofer IESE: „KI-Verordnung & funktionale Sicherheit“ — offene Auslegungsfragen zu Sicherheitsbauteil und redundanten Maßnahmen — iese.fraunhofer.de/blog/ki-verordnung-funktionale-sicherheit-von-ki/
[8] ISO/IEC 42001:2023 (AI Management System); flankierend ISO/IEC 23894:2023 (AI Risk Management), ISO/IEC 42005:2025 (AI System Impact Assessment), ISO/IEC TR 5469:2024 (Functional safety and AI systems) — iso.org
[9] Verordnung (EU) 2024/2847 (Cyber Resilience Act): Meldepflichten ab 11.09.2026, Vollanwendung 11.12.2027 — eur-lex.europa.eu/eli/reg/2024/2847/oj; BSI-Informationsseite (bsi.bund.de)
[10] Richtlinie (EU) 2024/2853 (neue Produkthaftungsrichtlinie): Software/KI als Produkt, Umsetzung bis 09.12.2026 — eur-lex.europa.eu/eli/dir/2024/2853/oj