KI in der Automotive-Softwareentwicklung: was heute trägt

KI in der Automotive-Softwareentwicklung: was bei Code, Requirements und Toolchain heute trägt

In Serienprojekten trägt Künstliche Intelligenz (KI) heute vier Einsatzfelder: Code-Assistenz mit Review- und Analyse-Pflicht, Qualitäts-Vorprüfung von Anforderungen, abfragbare Entwicklungsdokumentation mit Quellen- und Versionsanzeige sowie Unterstützung bei Testselektion und Testfall-Entwürfen. Keines dieser Felder ersetzt Urteil oder Freigabe des Menschen. sensified ordnet die vier Felder je nach Triage-Klasse ein und beschreibt den Freigabe- und Nachweispfad, der sie assessierbar hält.

Wer heute in einem Steuergeräte-Projekt nach Automotive SPICE (ASPICE) Software verantwortet, bekommt die Frage von zwei Seiten gestellt. Die Geschäftsführung fragt, warum das Team noch keine KI-Werkzeuge einsetzt. Die Qualitätssicherung fragt, wie ein KI-gestütztes Arbeitsergebnis durch das nächste Assessment kommen soll. Beide Fragen sind berechtigt, und beide lassen sich nur beantworten, wenn man die Werkzeug-Ebene sauber zerlegt: Welche Einsatzfelder gibt es, was leisten sie in Serienreife, und welcher Freigabepfad gehört zu jedem Feld. Dieser Beitrag ist der Überblick über diese Werkzeug-Ebene. Das zugrunde liegende Modell aus Tätigkeitsklassen, Wertströmen und Triage erläutert der Grundlagen-Beitrag zum Wertbeitrags-Prinzip im Automotive Software Engineering. Eine Einordnung vorweg: Die Anteils- und Eignungsaussagen sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Vier Einsatzfelder, ein Prüfmaßstab

Die Diskussion über KI in der Automotive-Softwareentwicklung zerfällt bei näherem Hinsehen in vier Einsatzfelder mit unterschiedlicher Reife und unterschiedlichem Risiko. Der Prüfmaßstab ist für alle vier derselbe: Ein Baustein trägt dann, wenn sein Arbeitsergebnis einen definierten Freigabepunkt beim Menschen durchläuft und die Evidenzkette für Assessments lückenlos bleibt.

Die Triage-Klassen folgen unserem Vorgehensmodell: A1 für regelgebundene Hintergrund-Automatisierung, A2 für vorbereitende Automatisierung mit Prüfpunkt beim Menschen, B für rein lesende Augmentation. Autonome Fallabwicklung (Klasse C) startet bei sensified grundsätzlich als nicht zulässig und wird nur nach expliziter Prüfung geöffnet. Die vollständige Logik beschreibt der Beitrag zur Triage zwischen Automatisierung und Augmentation im Engineering.

Code-Assistenz in der Seriensoftware

Code-Assistenz ist das sichtbarste Einsatzfeld und zugleich das, bei dem Serienkontext und Demo-Erlebnis am weitesten auseinanderliegen. Was im Prototypen beeindruckt, muss in der Seriensoftware durch Codier-Standards, statische Analyse und Review kommen.

Was heute trägt

Belastbar sind heute drei Muster. Erstens Assistenz bei Routine-Implementierung: Boilerplate, Zustandsautomaten nach vorgegebenem Schema, Unit-Test-Gerüste, Kommentierung und Dokumentationskommentare. Zweitens Erklär- und Analysearbeit: gewachsenen Code verständlich machen, Aufrufketten zusammenfassen, Kandidaten für Seiteneffekte markieren. Drittens Review-Vorbereitung: Diffs verdichten, Auffälligkeiten für den menschlichen Reviewer vorsortieren. Allen drei Mustern ist gemeinsam, dass sie Entwürfe und Sichten liefern, während der Commit- und Freigabepunkt unverändert beim Entwickler und beim bestehenden Review-Prozess liegt.

Wo die Grenze liegt

Die Grenze verläuft an der Konformität. Regelwerke wie MISRA C sind kein Stilthema; sie sind Freigabe-Voraussetzung, und ein Sprachmodell stellt ihre Einhaltung nicht sicher. Tragfähig ist deshalb nur die Kette aus KI-Vorschlag, statischer Analyse gegen das projektspezifische Regelwerk und verpflichtendem menschlichem Review. Hinzu kommt die Werkzeug-Frage der Funktionalen Sicherheit: Wo ein KI-Werkzeug Einfluss auf sicherheitsrelevante Arbeitsprodukte nimmt, gehört es in die Tool-Vertrauensbetrachtung nach ISO 26262, wie jedes andere Werkzeug der Kette auch. Wer diese Kette nicht aufsetzt, erzeugt mit KI schnelleren Code und langsamere Freigaben.

Requirements-Prüfung: Vorprüfung ja, Urteil nein

Das zweite Einsatzfeld liegt vor dem Code: die Qualität der Anforderungen. Sprachmodelle sind gut darin, Anforderungstexte gegen Schreibregeln zu prüfen und Kandidaten zu markieren: mehrdeutige Formulierungen, fehlende Verifizierbarkeit, Widersprüche und Dubletten über große Bestände, fehlende Abnahmekriterien.

Tragfähig wird das als rein lesende Vorprüfung: Das System markiert, der Requirements Engineer urteilt, und ein Feedback-Kanal fängt Fehlmarkierungen ein. Wie eine solche Vorprüfung mit Sprachmodellen im Detail aufgebaut wird, beschreibt der Leitfaden Requirements-Qualität mit LLMs prüfen. Das Konsistenz-Urteil über den Anforderungsbestand bleibt eine menschliche Entscheidung, ebenso die Klärungsarbeit mit dem Kunden. Wie sich diese Trennung in die gesamte Rolle einfügt, zeigt der Rollen-Deep-Dive zum Requirements Engineer mit KI in SWE.1. Der Gewinn liegt weniger in gesparten Minuten je Anforderung als in der Vorverlagerung: Mehrdeutigkeiten, die vor der Umsetzung auffallen, kosten eine Klärungsschleife. Dieselben Mehrdeutigkeiten im Integrationstest kosten einen Änderungsdurchlauf über mehrere Werkzeug-Grenzen.

Entwicklungsdokumentation: Antworten mit Quelle und Version oder gar nicht

Das dritte Einsatzfeld beantwortet eine Frage, die in fast jedem gewachsenen Projekt gestellt wird: Kann KI Fragen aus unserer Entwicklungsdokumentation beantworten? Die ehrliche Antwort lautet: ja, unter zwei Bedingungen. Die erste ist technisch: Eine abfragbare Doku-Sicht (Retrieval Augmented Generation, RAG) muss an die führenden Quellen angebunden sein, also an das Anforderungsmanagement, die Architektur- und Design-Ablagen und die Projekt-Wikis, mit ihren Zugriffsrechten. Die zweite ist methodisch: Jede Antwort braucht Fundstelle und Versionsstand. Eine Antwort ohne Quellenangabe ist im Serienkontext keine Auskunft; sie ist ein Gerücht mit guter Formulierung.

Unter diesen Bedingungen trägt das Feld erstaunlich weit: Einarbeitung neuer Teammitglieder, Zulieferer-Anfragen zu Schnittstellenständen, die Suche nach der Design-Entscheidung von vor drei Jahren. Es bleibt dabei eine Augmentations-Klasse: rein lesend, ohne eigenen Arbeitsstand, mit dem Menschen als letzter Instanz für jede Aussage, die das Haus verlässt.

Testunterstützung: Selektion und Generierung unter Nachweispflicht

Das vierte Einsatzfeld ist der Test, und hier ist die Nachweispflicht am unmittelbarsten. Änderungsbasierte Testselektion, also die Auswahl der Regressionstests, die zu einer konkreten Änderung laufen müssen, ist als vorbereitende Automatisierung mit Prüfpunkt gut beherrschbar: Das System schlägt die Auswahl vor, der Testverantwortliche bestätigt sie, und die Abdeckungsargumentation bleibt dokumentiert. KI-entworfene Testfälle sind ebenfalls nutzbar, aber jeder Entwurf durchläuft die Validierung, die auch für menschlich erstellte Testfälle gilt: Prüfung gegen die Anforderung, Review, Aufnahme in die Nachweiskette.

Wie groß der Druck auf genau dieser Strecke ist, zeigt eine Selbstauskunfts-Zahl aus der Branche: 46 % der Automotive-Teams fällt der Nachweis der ISO-26262-Konformität schwer (Quelle: Perforce, 2025). Werkzeuge, die Testaufwand senken, ohne die Nachweiskette zu tragen, verschieben das Problem also nur nach hinten, in Richtung Assessment. Wie die Rolle des Testverantwortlichen sich dadurch verändert, vertieft der Rollen-Deep-Dive zum Test-Ingenieur mit KI in SWE.4 bis SWE.6.

Der rote Faden: KI assistiert, der Mensch verantwortet

Über alle vier Felder hinweg gilt dieselbe Architektur der Verantwortung. KI-Bausteine liefern Entwürfe, Vorauswahlen und Sichten. Menschen treffen Urteile, geben frei und verantworten das Arbeitsergebnis. Diese Trennung ist keine Vorsichtsfloskel; sie ist der Grund, warum die Bausteine assessierbar bleiben.

„Ein KI-Baustein ist dann serienreif, wenn Sie dem Assessor in einem Satz sagen können, wer was wann freigegeben hat.“ Dazu gehört eine zweite Prüfung, die leicht übersehen wird: die Nebenwert-Prüfung. Manche mechanische Tätigkeit erzeugt nebenbei Verständnis, etwa wenn ein Entwickler beim Schreiben von Testfällen die Anforderung wirklich liest. Wer solche Tätigkeiten automatisiert, muss das Verständnis an anderer Stelle sichern, zum Beispiel über Bestätigungspflichten und Stichproben-Reviews. Und schließlich die Ordnung des Betriebs: versionierte Regelwerke, dokumentierte Rückholwege, lückenlose Protokollierung, klare Zuständigkeit je Baustein. Die Werkzeug-Ebene trägt genau so weit, wie diese Ordnung reicht.

Nächste Schritte

Welche der vier Einsatzfelder in Ihrem Projekt zuerst tragen, hängt von Toolchain, Datenlage und Evidenzpflichten ab und lässt sich nicht am Schreibtisch entscheiden. Der geordnete Einstieg sieht so aus:

1. Grundlagen lesen: Das Wertbeitrags-Prinzip im Automotive Software Engineering erklärt Tätigkeitsklassen, Wertströme und Triage im Zusammenhang.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus der Werkzeug-Ebene ein geführtes Transformationsvorhaben wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Scope, Toolchain und Ausgangslage Ihres Projekts zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zur Werkzeug-Ebene der KI in der Automotive-Softwareentwicklung zusammen. Sie beschreiben typisierte Einsatzfelder und Freigabepfade; wie die Felder in einem konkreten Projekt liegen, wird je Kunde und Toolchain geprüft.

Darf KI-generierter Code in Serienprojekte einfließen?

Ja, unter denselben Bedingungen wie jeder andere Code: statische Analyse gegen das projektspezifische Regelwerk, verpflichtendes menschliches Review und Freigabe über den bestehenden Merge-Prozess. Der KI-Vorschlag ist ein Entwurf, kein freigegebenes Arbeitsprodukt. Zusätzlich gehört das Werkzeug in die Tool-Vertrauensbetrachtung nach ISO 26262, sobald es sicherheitsrelevante Arbeitsprodukte beeinflusst.

Was leistet KI im Automotive-Engineering heute wirklich?

Vier Einsatzfelder tragen in Serienprojekten: Code-Assistenz mit Review-Pflicht, Qualitäts-Vorprüfung von Anforderungen, abfragbare Entwicklungsdokumentation mit Quellenangabe und Unterstützung bei Testselektion und Testfall-Entwürfen. Alle vier liefern Entwürfe und Sichten; Urteil, Freigabe und Verantwortung bleiben beim Menschen.

Ersetzt die Werkzeug-Ebene Entwicklerinnen und Entwickler?

Nein. Die Bausteine übernehmen Ausführungs- und Logistikanteile: Boilerplate, Vorsortierung, Zusammenstellen von Sichten. Urteils-, Klärungs- und Architekturarbeit bleibt beim Menschen, und genau dorthin verschiebt sich die gewonnene Zeit. Unsere Rollenkarten beschreiben diese Verschiebung je Rolle als typisierte Hypothese, die beim Kunden validiert wird; eine Bewertung einzelner Personen findet nicht statt.

Gefährdet der KI-Einsatz das nächste ASPICE-Assessment?

Nicht, wenn der Freigabepfad je Baustein steht. Assessoren bewerten die Erreichung der Prozess-Outcomes; entscheidend ist, dass jedes Arbeitsprodukt einen dokumentierten menschlichen Freigabepunkt hat und die Evidenzkette lückenlos bleibt. Riskant ist der umgekehrte Fall: informelle KI-Nutzung ohne Regelwerk, deren Ergebnisse unmarkiert in Arbeitsprodukte einfließen.

Kann KI Fragen aus unserer Entwicklungsdokumentation beantworten?

Ja, wenn zwei Bedingungen erfüllt sind: Anbindung an die führenden Quellen mit ihren Zugriffsrechten und Quellen- plus Versionsanzeige in jeder Antwort. Eine abfragbare Doku-Sicht arbeitet rein lesend und erzeugt keinen eigenen Arbeitsstand. Antworten ohne Fundstelle sind im Serienkontext nicht verwertbar.

Welche Rolle spielt die KI-Verordnung der EU für Engineering-Werkzeuge?

Werkzeug-KI im Engineering fällt überwiegend in niedrige Risikoklassen der KI-Verordnung (EU) 2024/1689, im Unterschied zu KI-Funktionen im Fahrzeug selbst. Es bleiben Pflichten wie die KI-Kompetenz der Beschäftigten, die seit Februar 2025 gilt, sowie Transparenz und dokumentierte Zuständigkeit. Die Einstufung gehört je Anwendungsfall geprüft, bevor ein Baustein in den Regelbetrieb geht.

Womit sollte ein Entwicklungsbereich anfangen?

Mit dem Feld, in dem Datenlage und Evidenzpflicht den schnellsten belastbaren Baustein erlauben. In vielen Projekten ist das die Qualitäts-Vorprüfung von Anforderungen oder die abfragbare Doku-Sicht, weil beide rein lesend arbeiten und keine Freigabeprozesse umbauen. Die Reihenfolge je Projekt ergibt sich aus einer Standortbestimmung entlang der Wertströme, wie sie die Seite zur AI-Transformation im Automotive Engineering beschreibt.