Funktionale Sicherheit, KI & Vibe Coding: Im Zweifel lieber vermeiden!

KI kann in der Embedded-Entwicklung Anforderungen umformulieren, Testideen erzeugen, Codefragmente schreiben und Dokumentation vorbereiten. Im Functional-Safety-Umfeld entsteht dabei jedoch immer ein Qualifikationsproblem. Denn Tools für die Codegenerierung fallen grundsätzlich immer unter die sogenannten T3-Tools, die gesondert zu qualifizieren sind, bzw. bei Sicherheitsfunktionen in der Regel ein Zertifikat erfordern. Denn: Ein Entwicklungswerkzeug darf sicherheitsbezogenen Code nur dann generieren, wenn sein Verhalten, seine Einsatzgrenzen und seine möglichen Fehler nachvollziehbar bewertet werden können. Bei generativen KI-Systemen ist diese Bewertung nur begrenzt möglich. Wie also sollen wir das Zusammenspiel Funktionale Sicherheit & KI bewerten? Ein detaillierter Blick auf diese komplexe Gemengelage.

Ausgangslage

Vibe Coding bezeichnet eine Arbeitsweise, bei der Software über natürlichsprachliche Prompts erzeugt und iterativ angepasst wird. Der Mensch beschreibt das gewünschte Verhalten, das Sprachmodell erzeugt Code, Tests oder Dokumentation, danach folgen weitere Prompts. In einfachen Prototypen kann diese Arbeitsweise die erste Umsetzung beschleunigen.

Functional Safety folgt einer anderen Logik. Sicherheitsbezogene Software muss aus Anforderungen abgeleitet, geprüft, rückverfolgbar dokumentiert und gegen definierte Akzeptanzkriterien verifiziert werden. Das betrifft etwa Automotive-Systeme nach ISO 26262, industrielle Systeme nach IEC 61508, Luftfahrtsoftware nach DO-178C mit Tool-Aspekten nach DO-330 oder Medizinprodukte-Software nach IEC 62304.

Was Software darf und was sie nicht darf, ist bspw. in der IEC 61508-3 relativ eindeutig geregelt. Der Einsatz von künstlicher Intelligenz wird dabei ausdrücklich nicht empfohlen, auch wenn KI hier in Form von Fehlerkorrektur bzw. fehlerkorrigierenden Verfahren genannt wird – das ist natürlich nur ein Teilaspekt funktionaler Sicherheit. KI bzw. Generative AI in seiner heutigen Form ist zudem sicher nicht das, was sich die Gremien 2010 unter KI vorgestellt haben.

Der Konflikt also entsteht, wenn KI-Ausgaben direkt in sicherheitsbezogene Artefakte einfließen. Ein Sprachmodell kann Code, Testfälle oder Safety-Argumente erzeugen. Daraus folgt aber kein Nachweis, dass diese Ergebnisse korrekt, vollständig oder normgerecht sind. Jedoch gibt es hier Abstufungen zu tätigen.

Fachlicher Hintergrund: Funktionale Sicherheit & KI

Bei Functional Safety gilt: ein Softwarefehler kann eine Sicherheitsfunktion beeinflussen, einen gefährlichen Zustand auslösen oder einen vorhandenen Fehler verdecken. Deshalb verlangen Safety-Prozesse Nachweise über Anforderungen, Architektur, Implementierung, Verifikation, Traceability, Konfigurationsmanagement und Reviews.

Tool-Qualifikation setzt an folgender Stelle an: Ein Werkzeug wird dann kritisch, wenn der Entwicklungsprozess auf seine korrekte Funktion vertraut und fehlerhafte Ausgaben nicht vollständig erkannt werden. Normativ sind sich da Automobilwelt, Industrie-Welt und alle anderen regulierten Branchen einig. ISO 26262 beschreibt dieses bspw. Prinzip über das Vertrauen in Softwaretools und betrachtet dabei die Möglichkeit, dass ein falsch funktionierendes Tool Fehler einbringt oder vorhandene Fehler nicht erkennt. IEC 61508 verfolgt denselben Grundgedanken. DO-330 formuliert sogar explizit ergänzende Leitlinien für Tool-Qualifikation im Luftfahrtkontext.

Tools unterscheiden sich dabei nach ihrer Wirkung. Ein Codegenerator kann Fehler in ein System einbringen. Ein Prüfwerkzeug kann Fehler übersehen. Für beide Fälle muss der Einsatzkontext betrachtet werden. Maßgeblich ist dabei die Frage, ob seine Ausgabe sicherheitsbezogene Entscheidungen beeinflusst und ob diese Ausgabe durch unabhängige Maßnahmen erkannt oder korrigiert wird.

Bei klassischen Tools lassen sich Funktionen, Versionen, Konfigurationen, Testfälle und bekannte Fehlerbilder oft beschreiben. Anbieter können Qualifikationspakete bereitstellen, etwa Testspezifikationen, erwartete Ergebnisse und Dokumentation für eine bestimmte Toolfunktion in einer bestimmten Umgebung. Bei generativen KI-Systemen ist diese Form der Eingrenzung schwieriger, weil Ausgaben promptabhängig, kontextabhängig und modellabhängig sind.

Generative AI für Funktionale Sicherheit

KI verändert Embedded-Arbeit an Stellen, an denen Schreibarbeit, Strukturierung und Variantenbildung anfallen. Ein Modell kann aus einer Anforderung Testideen ableiten, eine Traceability-Matrix vorbefüllen, MISRA-C-Hinweise erklären, Unit-Test-Gerüste erzeugen oder eine FMEA-Tabelle vorstrukturieren. Diese Tätigkeiten erzeugen Entwürfe, die anschließend fachlich geprüft werden können.

Das Safety-Problem beginnt dort, wo solche Entwürfe als geprüfte Artefakte behandelt werden. Ein KI-generierter Testfall ist zunächst ein Vorschlag. Er weist nicht nach, dass eine Anforderung vollständig getestet wurde. Ein KI-generierter Safety-Mechanismus ist zunächst eine Implementierungsidee. Er weist nicht nach, dass die Diagnoseabdeckung ausreicht oder dass Fehlannahmen ausgeschlossen wurden. Ein KI-generierter Review-Kommentar ist zunächst ein Hinweis. Er ersetzt kein Review mit dokumentierter Verantwortung.

Die These lautet daher: Für viele KI-basierte Entwicklungswerkzeuge wird eine klassische Tool-Qualifikation als Safety-Tool kaum tragfähig sein, wenn ihr Output nicht vollständig verifiziert wird. Der sinnvollere Prozess behandelt KI-Ausgaben als ungeprüfte Eingaben. Die Safety-Absicherung liegt dann in Anforderungen, Reviews, statischer Analyse, Tests, Coverage-Nachweisen, Traceability und unabhängiger Verifikation.

Tool-Qualifikation und generative KI

Eine Tool-Qualifikation verlangt eine belastbare Beschreibung des Werkzeugverhaltens im vorgesehenen Einsatz. Sie ist eine eigene Disziplin im Kontext Funktionale Sicherheit. KI hingegen ist von dieser Tool-Qualifikation weitestgehend unerfasst. Zur Tool-Qualifikation gehören typischerweise die verwendeten Funktionen, Konfigurationen und Auswahlmöglichkeiten, mögliche Fehlwirkungen, Maßnahmen zur Fehlererkennung und ein Nachweis, dass das Tool in der vorgesehenen Umgebung die erwarteten Ergebnisse liefert. Der Nachweis erfolgt über eine Kalotte detaillierter Testverfahren und ist nicht trivial.

Generative KI erschwert mehrere dieser Punkte:

• Das gleiche Ziel kann je nach Prompt, Kontext und Modellversion zu unterschiedlichen Ausgaben führen.
• Die innere Herleitung einer Ausgabe ist für das Entwicklungsteam nicht vollständig nachvollziehbar.
• Das Modell kann plausible, aber falsche Begründungen erzeugen.
• Der verfügbare Kontext kann bei größeren Codebasen unvollständig sein.
• Sicherheitsanforderungen können sprachlich korrekt wiedergegeben und technisch trotzdem falsch umgesetzt werden.
• Bei Codegenerierung können unsichere Muster, fehlende Eingabeprüfungen oder ungeeignete Bibliotheksnutzung entstehen.

Diese Eigenschaften schließen KI-Nutzung nicht aus. Sie verändern aber die Rolle des Tools. Wenn die KI nur Entwürfe liefert und alle sicherheitsbezogenen Ergebnisse durch qualifizierte oder anderweitig abgesicherte Prozesse geprüft werden, hängt der Safety-Nachweis nicht von der korrekten KI-Funktion ab. Wenn ein Projekt dagegen ungeprüft auf KI-Ausgaben vertraut, müsste die KI selbst als Safety-relevantes Tool bewertet werden. Genau dort entsteht die kaum lösbare Qualifikationsfrage.

Zulässige und problematische Einsatzmuster

Für nicht sicherheitsbezogenen Code kann Vibe Coding breiter eingesetzt werden, sofern Reviews, Tests und Konfigurationsmanagement greifen. Bei sicherheitsbezogener Software sinkt der Spielraum mit der Kritikalität.

Bei ASIL A/B oder SIL 1/2 kann KI bei vorbereitenden Tätigkeiten helfen. Beispiele sind Requirements-Zerlegung, Testfallentwürfe, Boilerplate-Code, Review-Checklisten, MISRA-Erklärungen oder Vorschläge für Range Checks, Timeout Handling, Watchdog Supervision und CRC-Prüfungen. Der Output muss anschließend durch den vorgesehenen Entwicklungsprozess laufen.

Bei ASIL C/D oder SIL 3/4 sollte KI-generierter Code nur in eng abgegrenzten Einheiten eingesetzt werden. Geeignet sind Funktionen mit klaren Eingängen, klaren Ausgängen und vollständiger Prüfbarkeit. Für sicherheitsbezogene Logik sind menschliche Reviews, unabhängige Tests und bei kritischen Teilen formale oder semi-formale Nachweise naheliegende Maßnahmen.

Problematisch sind Einsatzmuster, bei denen KI die Safety-Autorität übernimmt. Dazu gehören ungeprüfte ASIL-D-Logik, automatisch finalisierte Safety Requirements, geschätzte Diagnoseabdeckung, übersprungene Reviews oder eine Toolchain-Qualifikation, die durch KI-Ausgaben ersetzt werden soll.

Wo generative AI wohl gedultet werden wird

Generative KI in der Softwareentwicklung wird sich in sicherheitskritischen Projekten nicht dauerhaft ausklammern lassen. Besonders deutlich wird das beim Thema Code-Snippets. Gemeint sind einzelne Codeschnipsel, Hilfsfunktionen, Umformungen, Initialisierungen, Testhilfen oder klar abgegrenzte Implementierungsteile, die auf Basis eines präzisen Prompts erzeugt werden. Die KI übernimmt dabei nicht die Verantwortung für Architektur, Safety-Konzept, Requirements, Teststrategie oder Freigabe. Sie wirkt eher wie eine produktivere Form der Entwicklungsumgebung: eine „verlängerte Tastatur“ mit Vorschlagsfunktion.

Genau darin liegt die eigentliche Herausforderung für funktionale Sicherheit. Wenn Entwickler generative KI nutzen, um einzelne Teilaspekte schneller zu formulieren, ist ein pauschales Verbot praktisch schwer durchsetzbar. Für sicherheitskritische Systeme ist deshalb nicht die erste Frage, ob generative KI grundsätzlich „erlaubt“ oder „verboten“ werden sollte. Die relevantere Frage lautet: Unter welchen Bedingungen darf ein KI-generierter Codeausschnitt in ein sicherheitsrelevantes Entwicklungsartefakt übernommen werden?

Eine belastbare Regel kann nicht lauten: „Die KI hat es erzeugt, also ist es falsch.“ Sie kann aber auch nicht lauten: „Der Entwickler hat es übernommen, also ist es ausreichend geprüft.“

KI-generierte Snippets müssen wie fremder, nicht qualifizierter Code behandelt werden und sollten stets per Prozess integriert werden. Das bedeutet konkret im Kontext Funktionale Sicherheit: KI Snippets dürfen nur dann verwendet werden, wenn der Entwickler den Code vollständig versteht, seine Funktion gegen die zugehörigen Requirements prüfen kann und keine ungeklärten Annahmen aus dem Prompt oder aus der Modellantwort übernimmt.

Damit verschiebt sich die Rolle der Organisation. Sie muss nicht nur entscheiden, ob KI-Werkzeuge erlaubt sind. Sie muss definieren:

• welche Artefakte entstehen dürfen,
• wie Prompts dokumentiert werden,
• ob KI-generierter Code markiert werden muss,
• welche Review-Tiefe erforderlich ist;
• welche Codebereiche ausgeschlossen sind.

Die Alternative wäre eine gremiale oder gesellschaftliche Entscheidung, die Nutzung generativer KI in sicherheitskritischen Systemen explizit zu untersagen. Das wäre ein klarer, aber harter Ansatz. Er hätte den Vorteil eindeutiger Regeln, aber auch erhebliche praktische Schwächen: Er müsste kontrollierbar sein, dürfte keine Schattennutzung erzeugen und müsste gegenüber Produktivitätsdruck, Fachkräftesituation und internationalem Wettbewerb bestehen.

Technische Grenzen

Ungeachtet aller Punkte müssen die technischen Grenzen beleuchtet werden.

Sprachmodelle können bei größeren Codebasen Zusammenhänge verlieren. Änderungen können entfernte Abhängigkeiten beeinflussen. Generierter Code kann uneinheitliche Strukturen, doppelte Logik oder verdeckte Annahmen enthalten. Sicherheitskritische Software erfordert außerdem kontrollierte Versionen, reproduzierbare Builds und nachvollziehbare Änderungen. Prompt-Historien allein erfüllen diese Rolle nicht.

Als größter Blocker für eine flächendeckende Nutzung für Funktionale Sicherheit: KI hat eine Randomness. Denn es gibt eine inhärente Nicht-Deterministik generativer KI. Derselbe Prompt kann zu unterschiedlichen Code-Snippets führen, abhängig von Modellversion, Parametern, Kontextfenster, Temperatur, Anbieter oder Tool-Integration. Für funktionale Sicherheit ist das ein Problem, weil sicherheitskritische Entwicklung auf Reproduzierbarkeit angewiesen ist.

Was geht und was nicht geht

Ein tragfähiger Prozess trennt KI-Assistenz von einer Verantwortungsverlagerung des Themas Funktionaler Sicherheit. KI liefert dann maximal Entwürfe oder Snippets. Das muss im Zweifelsfalle auch belegt werden. Die Organisation als Ganzes legt fest, welche Entwürfe übernommen werden, welche Prüfungen erfolgen und welche Nachweise im Safety Case verwendet werden. Das kann funktionieren, muss aber gleichzeitig an strenge Regeln gebunden werden, die Nachweise benötigen werden.

Ein paar Beispiele für solche Regeln:

• Code wird nur nach Review und statischer Analyse (PASS) übernommen
• Traceability wird nicht aus KI-Texten abgeleitet, sondern gegen reale Artefakte geprüft.
• Ein Prompt wird mehrmals ausgeführt. Verschiedene Ergebnisse werden per Diff gegeneinander geprüft
• Es gilt stets das 4-Augen-Prinzip
• Generierte Snippets werden als solche gekennzeichnet. Ein Ansatz ist ein Markup im Code oder im Ticket.
• Reviews und unabhängige Verifikation bleiben stets manuell dokumentierte Prozessschritte.

Fazit

Generative KI wird in der Embedded-Entwicklung nicht verschwinden, auch nicht im Umfeld funktionaler Sicherheit. Entscheidend ist deshalb nicht ein pauschales Ja oder Nein, sondern ein belastbarer Prozess: KI-generierte Snippets müssen wie nicht qualifizierter Fremdcode behandelt, verstanden, geprüft, dokumentiert und verifiziert werden. Für sicherheitskritische Systeme darf KI Produktivität liefern, aber niemals Verantwortung, Tool-Qualifikation oder Safety-Nachweise ersetzen.