All News

Produkt

|

June 18, 2026

EU AI Act: Was bedeutet das für KI im Engineering?

Die Frist läuft bis 2027. Hier die entscheidenden Anforderungen und warum sie bereits jetzt relevant sind

Kurzfassung: Die Anforderungen des EU-KI-Gesetzes hinsichtlich Rückverfolgbarkeit, Protokollierung und menschlicher Aufsicht beschreiben genau das, was seriöse Ingenieurspraxis ohnehin bereits umsetzt. Horizontale KI-Tools wurden nicht dafür entwickelt, diese Anforderungen zu erfüllen. Spezialisierte KI für den Ingenieurbereich, die auf deterministischen Arbeitsabläufen basiert, tut dies hingegen bereits. Die Diskussion um Audits wird erst 2027 aufkommen, doch die Sicherheitsfragebögen Ihrer nachgelagerten Kunden treffen bereits in diesem Quartal ein. Das Gesetz sagt Ihnen in juristischer Sprache, wie gute Ingenieurspraxis mit KI schon immer aussehen musste.

Als ich das EU-KI-Gesetz zum ersten Mal vollständig las, dachte ich, die für ein Ingenieurunternehmen relevanten Teile seien diejenigen über Sicherheitskomponenten in regulierten Produkten. Darauf wiesen auch die meisten frühen Kommentare hin. Acht Monate später, nach ein paar Dutzend Kundengesprächen und einem langen Gespräch mit einem Beschaffungsbeauftragten, der die Verordnung besser kannte als ich, glaube ich, dass ich mich hinsichtlich der wichtigen Teile geirrt habe.

Die Teile, die für einen Leiter der Entwicklungsabteilung oder einen Forschungs- und Entwicklungsleiter, der eine CAD- und Simulations-Pipeline betreibt, von Bedeutung sind, sind genau jene, über die fast niemand spricht. Sie befinden sich nicht im Abschnitt über hohe Risiken. Sie sind in den Anforderungen an die Rückverfolgbarkeit, die Aufbewahrung von Aufzeichnungen, die menschliche Aufsicht und die Datenverwaltung zu finden. Das sind die Anforderungen, die Ihre Entwicklungswerkzeuge erfüllen müssen, unabhängig davon, ob ein einzelner Workflow darin jemals als risikoreich eingestuft wird.

Was das Gesetz von der KI im Ingenieurwesen verlangt 

Das Gesetz basiert auf einer vierstufigen Einstufung, wobei die höchste Stufe (verboten) und die zweite Stufe (hohes Risiko) im Mittelpunkt der Aufmerksamkeit stehen. Die meisten Arbeitsabläufe in der Forschung und Entwicklung werden darunter liegen, im Bereich mit begrenztem oder minimalem Risiko. Das ist beim ersten Lesen beruhigend, beim zweiten jedoch ein wenig irreführend.

Es ist irreführend, weil die Anforderungen an Systeme mit hohem Risiko genau dieselben sind, die Sie ohnehin schon erfüllen sollten – auch wenn das Gesetz dies nicht von Ihnen verlangt:

  • Artikel 9 schreibt einen dokumentierten Risikomanagementprozess über den gesamten Lebenszyklus hinweg vor.  
  • Artikel 10 schreibt vor, dass die vom System verwendeten Daten relevant, repräsentativ und nachvollziehbar sein müssen.  
  • Artikel 11 schreibt eine technische Dokumentation vor, die es einer Aufsichtsbehörde ermöglicht, die Funktionsweise des Systems nachzuvollziehen.  
  • Artikel 12 schreibt vor, dass jede Ausführung protokolliert und mindestens sechs Monate lang abrufbar sein muss.  
  • Artikel 13 schreibt vor, dass die Nutzer die Ergebnisse des Systems und dessen Grenzen verstehen müssen.  
  • Artikel 14 schreibt eine integrierte menschliche Überwachung an den entscheidenden Kontrollpunkten vor.

Diese sechs Anforderungen stellen, losgelöst von den sie umgebenden gesetzlichen Formulierungen, eine Beschreibung guter ingenieurtechnischer Praxis dar. Das Gesetz schreibt der Ingenieursbranche in diesem Zusammenhang nichts Fremdes vor. Es hält lediglich fest, was in der seriösen Ingenieurspraxis ohnehin bereits umgesetzt wird, und fordert alle anderen auf, hier aufzuholen.

Wo horizontale KI-Tools an ihre Grenzen stoßen werden

KI für Unternehmen gibt es in zwei Formen. Horizontale KI-Tools sind allgemeine „Copiloten“, die in einem Browser-Tab laufen und versuchen, bei jeder Aufgabe hilfreich zu sein. Vertikale KI-Tools sind spezialisierte Plattformen, die für einen bestimmten Bereich entwickelt wurden. Iin unserem Fall das Ingenieurwesen, wobei der Workflow selbst das Produkt ist.

Die Tools, die Ihre Ingenieure bereits in ihrem Browser-Tab nutzen, wurden für nichts davon entwickelt. Sie wurden entwickelt, um am Einsatzort hilfreich zu sein, nicht um im Nachhinein rekonstruierbar zu sein.

Diese Lücke zeigt sich an drei Stellen. Die Datenherkunft bricht in dem Moment ab, in dem der Tab geschlossen wird. Das Interaktionsmodell verlangt keinen Nachweis menschlicher Aufsicht, da das Modell der Assistent und der Mensch der Nutzer ist, nicht umgekehrt. Und die technische Dokumentation, die eine Aufsichtsbehörde verlangen würde, wird durch einen Chat-Verlauf ersetzt.

Der Vorfall bei Samsung, bei dem Halbleiteringenieure Daten aus Chip-Ausbeutetests über Nacht in Trainingsdaten umwandelten, indem sie diese in ein öffentliches Chat-Tool einfügten, war das erste Warnsignal. Die darauf folgende Welle von Verboten in Unternehmen war keine Panikreaktion. Es war die Erkenntnis, dass das Standardverhalten dieser Tools für technische Daten falsch ist.

Das bedeutet keineswegs, dass horizontale Copiloten unbrauchbar werden. Es bedeutet vielmehr, dass ihr natürlicher Platz in einer Entwicklungsorganisation neben den regulierten Entscheidungen liegt, nicht innerhalb dieser. Sie dienen dem Brainstorming, ersten Zusammenfassungen und Code-Schnipseln, die der Ingenieur ohnehin neu schreiben wird. Sie werden nicht innerhalb des Arbeitsablaufs eingesetzt, der damit endet, dass ein Bauteil in ein Fahrzeug eingebaut wird.

Was ein „nachvollziehbarer digitaler Faden“ eigentlich bedeuten muss

Der Begriff „prüfbarer und nachvollziehbarer digitale Thread“ wird im Marketing für Engineering-Software so salopp verwendet, dass er für viele Führungskräfte aus dem Ingenieurswesen, mit denen ich spreche, mittlerweile jeglichen Inhalt verloren hat. Es lohnt sich, genau zu definieren, was dieser Begriff bedeuten muss, wenn er die Anforderungen des Gesetzes erfüllen soll.

Das bedeutet:

  • Die Eingaben zu jeder Entscheidung werden versioniert und sind abrufbar.  
  • KI-Komponenten innerhalb des Workflows werden benannt, versioniert und neben den deterministischen Komponenten im Ausführungsprotokoll erfasst.  
  • Die Person in der Aufsichtsfunktion wird identifiziert, und der Zeitpunkt ihrer Überprüfung wird mit einem Zeitstempel versehen.  
  • Das Ergebnis lässt sich anhand der Eingaben und der Workflow-Definition reproduzieren, nicht anhand eines Chat-Verlaufs.  
  • Der gesamte Verlauf muss mindestens sechs Monate lang aufbewahrt werden; dies ist die im Gesetz in Artikel 12 festgelegte Mindestdauer, die die meisten technischen Organisationen jedoch verlängern möchten.

Genau das muss ein nachverfolgbarer digitale Thread bedeuten. Alles andere ist unvollständig.

Warum Synera die gesetzlichen Anforderungen bereits erfüllt

Synera wurde entwickelt, bevor das Gesetz endgültig verabschiedet war. Die Architektur, die schließlich entstand, entspricht den Anforderungen des Gesetzes ungewöhnlich gut, da sich herausstellte, dass die Vorgaben, die die Entwicklung bestimmten (Vertrauen in die Technik, Reproduzierbarkeit, Speicherung der Kundendaten vor Ort), genau den Vorgaben entsprachen, auf die sich die Regulierungsbehörden einigten:

  • Die visuellen Workflows der Plattform sind Node-basiert, was bedeutet, dass jeder Schritt explizit und nachvollziehbar ist. Die Workflows sind genau die technische Dokumentation, die Artikel 11 benötigt, da sie genau beschreiben, was das System tut.
  • Jeder Workflow-Durchlauf erzeugt ein versioniertes Artefakt, das die in Artikel 12 geforderte Aufzeichnung darstellt, da die Aufzeichnung nicht über ein nachträglich angefügtes Protokollierungssystem erfolgt, sondern ein fester Bestandteil der Funktionsweise der Plattform ist.
  • Die agentenbasierten KI-Fähigkeiten kommen innerhalb der Arbeitsabläufe zum Einsatz, und zwar genau an den Stellen, an denen eine Interpretation erforderlich ist. Der deterministische Entwicklungsprozess fungiert dabei als Koordinator. Das große Sprachmodell (LLM) ist ein Werkzeug innerhalb dieses Prozesses. Durch diese Anordnung wird die in Artikel 14 festgelegte Vorgabe „auf menschliche Aufsicht ausgelegt“ zur Standardlösung und nicht erst nachträglich eingebaut.

Kundendaten verbleiben innerhalb der bestehenden Tool-Landschaft des Kunden (CATIA, NX, SolidWorks, Ansys, Abaqus und siebzig weitere). Sie werden nicht in den Trainingskorpus eines Basismodells eingespeist – das ist die Frage aus Artikel 10, ohne den regulatorischen Wortlaut. Und die TISAX-Zertifizierung der Stufe 2 von Synera, die dem Informationssicherheitsstandard der deutschen Automobilbranche entspricht, ist die derzeit beste Beleggrundlage für die Art von Datenverwaltung, die das Gesetz nun von jedem Anbieter von KI-Lösungen für den Ingenieurbereich verlangt.

Das Gesetz fragt: Kannst du rekonstruieren, was passiert ist? Das Engineering fragt bereits: Kannst du ein Ergebnis reproduzieren? Die Architektur, die die eine Frage beantwortet, beantwortet beide.

Was Führungskräfte aus der Luft- und Raumfahrt sowie der Automobilbranche in diesem Quartal tun sollten

Die maßgeblichen Fristen liegen in den Jahren 2027 und 2028, doch die Gespräche im Rahmen der Prüfung haben bereits in abgeschwächter Form begonnen, da in diesem Quartal die Sicherheitsfragebögen unserer Kunden eintreffen. Wo werden unsere Daten gespeichert? Was wird protokolliert? Wer überwacht die KI? Wie werden Sie dies nachweisen?

Die Anbieter, die diese vier Fragen ohne zu zögern beantworten können, sind diejenigen, deren Roadmaps für KI-Lösungen im Jahr 2027 sich auf Funktionen konzentrieren werden. Diejenigen, die dies nicht können, werden das Jahr 2027 damit verbringen, Compliance-Funktionen in ein Produkt nachzurüsten, dessen Architektur auf anderen Annahmen basiert – eine langwierige und kostspielige Aufgabe, die parallel zu den tatsächlichen Anforderungen Ihrer Entwicklungsabteilung erledigt werden muss.

Der tiefgreifendere Schritt besteht darin, zu erkennen, dass das Gesetz in diesem Sinne weniger eine Einschränkung als vielmehr eine Klarstellung darstellt. Es sagt Ihnen in juristischer Sprache, wie gute Entwicklung mit KI schon immer aussehen musste. Die Teams, die dies am frühesten verinnerlichen, werden nicht diejenigen sein, deren Unterlagen am ordentlichsten sind, wenn der Prüfer kommt. Es werden diejenigen sein, deren Entwickler in zwei Jahren immer noch entwickeln, weil die ihnen zugrunde liegenden Werkzeuge so konzipiert wurden, dass sie Bestand haben.

About the Author:

Ram Seetharaman

Head of AI

Ram Seetharaman ist Head of AI bei Synera und leitet die Multi-Agenten- und agentenbasierten KI-Initiativen des Unternehmens, die die Art und Weise neu definieren, wie Ingenieurteams komplexe Produkte entwerfen, simulieren und automatisieren. Mit seinem Hintergrund in Computational Mechanics von der Universität Stuttgart und fünf Jahren Erfahrung in der Anwendung von ML und KI auf ingenieurtechnische Arbeitsabläufe schlägt er eine Brücke zwischen fundierter technischer Forschung und Entwicklung sowie Produktstrategie. Bei Synera ist er für die KI-Strategie, die Roadmap und die Umsetzung verantwortlich und setzt Fachwissen in KI-gesteuerte Arbeitsabläufe um, die Simulation, Designraumerkundung und Automatisierung in großem Maßstab beschleunigen. Vor seiner Tätigkeit bei Synera war Ram als Digital-Twin- und Strukturoptimierungsingenieur an preisgekrönten Motorsport- und Luftfahrtprojekten beteiligt, wurde 2023 Weltmeister und arbeitete bei Volocopter an sicherheitskritischen Batteriecrash-Simulationen.

Jetzt loslegen!

Sehen Sie sich eine Live-Demo eines Synera-Multi-Agenten-Systems an.

Sehen Sie unsere innovativen Lösungen in Aktion. In diesem Video präsentiert Mike, unser Head of Pre-Sales, ein Multi-Agenten-System in Echtzeit.

Live-Demo