KI-Coding-Assistenten im Embedded-Team einführen

KI-Coding-Assistenten im Embedded-Team einführen: IP-Schutz, Konformität, Akzeptanz

Die Einführung eines KI-Coding-Assistenten in einem Embedded-Team gelingt, wenn drei Spannungsfelder gleichzeitig geordnet werden: der Schutz des geistigen Eigentums über eine bewusste Deployment-Entscheidung und vertragliche Zusicherungen, der Konformitätsrahmen mit unveränderter Review-Pflicht und statischer Analyse sowie die Akzeptanz im Team über einen freiwilligen Pilot mit vorab definierten Messgrößen. Der Quellcode verlässt das Haus dabei nur, wenn die Deployment-Entscheidung das ausdrücklich vorsieht, und jeder KI-Vorschlag durchläuft denselben Freigabepfad wie menschlich geschriebener Code. Wer eines der drei Felder überspringt, bezahlt später mit IP-Vorfällen, Assessment-Risiken oder stiller Verweigerung im Team. sensified beschreibt in diesem Beitrag den Einführungspfad von der Deployment-Entscheidung bis zum Pilot-Design und ordnet jeden Schritt in den Freigabepfad je Triage-Klasse ein.

Die Ausgangslage ist in vielen Häusern dieselbe. Die Geschäftsführung hat entschieden, dass KI-Werkzeuge in die Entwicklung kommen, und erwartet sichtbare Ergebnisse noch in diesem Jahr. Im Team kursieren zugleich andere Fragen: Was passiert mit unserem Code? Wer trägt die Verantwortung, wenn ein Vorschlag einen Fehler ins Steuergerät bringt? Und zählt künftig jemand mit, wie viele Zeilen die Einzelne oder der Einzelne schreibt? Die Entwicklungsleitung steht zwischen beiden Erwartungen und soll die Einführung verantworten. Dieser Beitrag beschreibt den organisatorischen Pfad für genau diese Lage. Was Code-Assistenz in Serienprojekten fachlich heute leistet und wo ihre Grenzen liegen, ordnet der Überblicks-Beitrag zu KI in der Automotive-Softwareentwicklung ein. Eine Einordnung vorweg: Eignungs- und Erfahrungsaussagen in diesem Text sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Drei Spannungsfelder, eine Reihenfolge

Einführungen scheitern selten am Werkzeug selbst. Sie scheitern daran, dass eines von drei Spannungsfeldern unbeantwortet bleibt und die offene Frage die gesamte Einführung blockiert. Es lohnt sich deshalb, die drei Felder vor dem ersten Werkzeug-Test zu benennen und jedem Feld ein Instrument zuzuordnen.

Die Reihenfolge ist dabei kein Detail. Die Deployment- und Vertragsfrage steht am Anfang, weil vor ihrer Klärung kein einziger Prompt mit echtem Projektcode laufen darf. Der Konformitätsrahmen folgt vor dem Pilot, damit der Pilot unter Serienbedingungen misst. Die Akzeptanzarbeit beginnt am ersten Tag und endet nicht mit dem Pilot. Für die Einordnung der Tätigkeiten nutzt sensified die Triage-Klassen aus dem Beitrag zur Triage zwischen Automatisierung und Augmentation im Engineering: A1 steht 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 grundsätzlich als nicht zulässig. Ein Coding-Assistent arbeitet in den Klassen A2 und B: Er liefert Entwürfe mit Prüfpunkt beim Entwickler und erklärt bestehenden Code rein lesend.

IP-Schutz: Quellcode verlässt das Haus nicht ohne Entscheidung

Der erste Einwand kommt fast immer zuerst, und er ist berechtigt. Steuergeräte-Code enthält Betriebsgeheimnisse des eigenen Hauses, häufig auch Fremd-IP des OEM oder anderer Zulieferer, teils unter expliziten Vertraulichkeitsauflagen aus Kundenverträgen. Ein Werkzeug, das Quelltext an einen externen Dienst sendet, berührt damit Vertragsrecht und Informationssicherheit gleichermaßen. Die Antwort darauf ist keine pauschale Absage an Cloud-Dienste. Die Antwort ist eine dokumentierte Entscheidung.

Deployment-Optionen von on-premise bis EU-gehostet

Drei Betriebsmodelle decken die Bandbreite ab. Am einen Ende steht der On-Premise-Betrieb: Sprachmodell und Kontext bleiben vollständig auf eigener Infrastruktur. Das ist die stärkste IP-Position, verlangt aber eigenen Betriebsaufwand für Modelle, Hardware und Aktualisierung, und die verfügbaren Modelle sind in der Regel kleiner als die großen Cloud-Modelle. In der Mitte liegt die dedizierte, EU-gehostete Instanz eines Anbieters: Verarbeitung in der EU, vertraglich zugesicherter Ausschluss der Trainingsnutzung, definierte Löschfristen. Am anderen Ende steht der SaaS-Dienst mit Enterprise-Vertrag und Zusagen zur Datenhaltung. Welche Option trägt, entscheiden die strengsten Auflagen im Portfolio: Ein Bereich, der unter Kundenauflagen mit besonderer Vertraulichkeit arbeitet oder sich in einem Informationssicherheits-Rahmen wie TISAX® bewegt, braucht eine härtere Option als ein Bereich mit ausschließlich eigenem Code. Viele Häuser fahren deshalb zweigleisig: eine restriktive Option für auflagenbehaftete Projekte, eine komfortablere für den Rest, mit technischer Trennung dazwischen.

Vertragliche Zusicherungen, die vor der Freigabe stehen

Unabhängig vom Betriebsmodell gehören fünf Zusicherungen schriftlich fixiert, bevor der erste Projektcode das Werkzeug erreicht: der Ausschluss der Nutzung von Eingaben und Ausgaben für das Training von Modellen, Speicher- und Löschfristen für übermittelte Inhalte, der Verarbeitungsort einschließlich der Unterauftragsverhältnisse, Auskunfts- und Audit-Rechte sowie die Regelung der Rechte an generierten Vorschlägen. Dazu kommen technische Kontrollen im eigenen Haus: Welche Repositories sind angebunden, welche sind ausgeschlossen, und wie wird verhindert, dass Code aus auflagenbehafteten Kundenprojekten in eine nicht dafür freigegebene Instanz gelangt. Diese Liste ist keine Juristerei um ihrer selbst willen. Sie ist die Grundlage, auf der die Entwicklungsleitung die IP-Frage gegenüber Kunden und Geschäftsführung in einem Satz beantworten kann.

Konformitätsrahmen: der Freigabepfad ändert sich nicht

Die zweite Sorge betrifft das nächste Assessment, und auch sie hat einen realen Kern. Der Nachweisdruck in der Branche ist hoch: 46 % der Automotive-Teams fällt der Nachweis der ISO-26262-Konformität schwer (Quelle: Perforce, 2025). Ein neues Werkzeug, das diese Lage verschärft, wäre ein schlechter Tausch. Die Antwort liegt in einem Grundsatz, der sich durch die gesamte Einführung zieht: Der Freigabepfad für Arbeitsprodukte ändert sich durch den Assistenten nicht.

Freigabepfad je Triage-Klasse

Für Vorschlagsarbeit in Klasse A2 gilt: Jeder Vorschlag ist ein Entwurf. Der Commit-Punkt bleibt beim Entwickler, das Review bleibt verpflichtend, und die Freigabe läuft über den bestehenden Merge-Prozess. Für Erklär- und Analysearbeit in Klasse B gilt: rein lesender Zugriff, kein eigener Arbeitsstand, das Urteil über jede Aussage liegt beim Menschen. Autonome Fallabwicklung, also Klasse C, startet als nicht zulässig und wird nur nach expliziter Prüfung für eng umrissene Fälle geöffnet. Das Regelwerk der Einführung benennt je Tätigkeit, in welcher Klasse der Assistent arbeiten darf, und dieser Freigabepfad ist das Dokument, das im Assessment trägt. Wer dem Assessor in einem Satz sagen kann, wer was wann freigegeben hat, hat die Konformitätsfrage beantwortet.

Statische Analyse bleibt, Review bleibt

Codier-Regelwerke wie MISRA C sind Freigabe-Voraussetzung, und ein Sprachmodell stellt ihre Einhaltung nicht sicher. Tragfähig ist allein die Kette aus KI-Vorschlag, statischer Analyse gegen das projektspezifische Regelwerk und verpflichtendem menschlichem Review. Was Sprachmodelle an MISRA-Konformität tatsächlich leisten und an welchen Regelklassen sie scheitern, vertieft der Beitrag zu LLMs und MISRA-konformem C-Code. Hinzu kommt die Werkzeug-Frage der Funktionalen Sicherheit: Sobald der Assistent Einfluss auf sicherheitsrelevante Arbeitsprodukte nimmt, gehört er in die Tool-Vertrauensbetrachtung nach ISO 26262, wie jedes andere Werkzeug der Kette. Für die Einführung heißt das konkret: Die statische Analyse wird nicht gelockert, um dem neuen Werkzeug Geschwindigkeit zu verschaffen. Sie ist der Grund, warum das Team dem Werkzeug überhaupt trauen darf.

Team-Akzeptanz: Skepsis ernst nehmen

Das dritte Spannungsfeld ist das leiseste, und es entscheidet am Ende über die Wirkung. Ein Werkzeug, das eingeführt, aber nicht angenommen wird, erzeugt Lizenzkosten und Berichtsfolien, aber keinen Wertbeitrag. Und ein Team, das die Einführung als Misstrauensvotum liest, wird das Werkzeug still umgehen.

Was hinter der Skepsis steckt

Die Datenlage zeigt, dass die Skepsis kein Sonderfall des eigenen Teams ist. Laut Developer Survey nutzen oder planen 84 % der Entwicklerinnen und Entwickler den Einsatz von KI-Werkzeugen, zugleich misstrauen 46 % der Genauigkeit der Ausgaben und nur 33 % vertrauen ihr; 66 % nennen als größte Frustration KI-Lösungen, die fast richtig, aber nicht ganz richtig sind, und 45 % geben an, dass das Debuggen KI-generierten Codes mehr Zeit kostet (Quelle: Stack Overflow, 2025). Erfahrene Entwickler sind in derselben Erhebung die vorsichtigste Gruppe. Für die Entwicklungsleitung ist das eine gute Nachricht: Die Prüfhaltung, die sich in diesen Zahlen zeigt, ist exakt die Haltung, die der Freigabepfad braucht. Skepsis gegenüber generiertem Code ist im Serienkontext eine Qualifikation. Die Einführung muss sie nicht überwinden, sie muss sie einbauen.

Pilot mit Freiwilligen, Messgrößen vor dem Start

Aus dieser Haltung folgen drei Festlegungen. Erstens: Der Pilot läuft mit Freiwilligen. Wer skeptisch ist, darf zuschauen und wird nicht verpflichtet; wer teilnimmt, bringt echtes Interesse und ehrliche Rückmeldung mit. Zweitens: Die Messgrößen werden vor dem Pilot definiert und dem Team offengelegt, nicht nachträglich zusammengesucht, wenn ein Ergebnis gebraucht wird. Drittens: Es gibt kein Überwachungs-Framing. Gemessen wird auf Team-Ebene, etwa Durchlaufzeiten und Befundraten; Auswertungen je Person, Zeilen-Zählungen oder Nutzungs-Ranglisten finden nicht statt, und das wird ausdrücklich zugesagt. Wie sich Tätigkeitsprofile durch KI-Assistenz je Rolle verschieben können, beschreiben die Rollenkarten zu ASPICE-Rollen und ihrem KI-Potenzial als typisierte Hypothesen. Genau diese Trennung zwischen Rollen-Betrachtung und Personen-Bewertung gehört in die Kommunikation der Einführung.

Pilot-Design: sechs Festlegungen vor dem ersten Einsatz

Ein Pilot ist kein Ausprobieren mit offenem Ende. Er ist ein zeitlich begrenztes Experiment mit definiertem Rahmen, dessen Ergebnis eine Entscheidung ermöglicht. Sechs Festlegungen gehören vor den Start.

Die Rahmenwerte in der rechten Spalte sind typisierte Erfahrungswerte, die je Team, Projektlage und Toolchain anzupassen sind. Zwei Punkte verdienen besondere Sorgfalt. Die Abbruchkriterien nehmen der Skepsis im Team die Schärfe, weil sie zeigen, dass die Leitung das Risiko ernst nimmt und einen definierten Ausstieg hat. Und die offene Entscheidung am Ende verhindert den häufigsten Pilot-Fehler: ein Ergebnis, das nie formal bewertet wird und als Dauerprovisorium weiterläuft.

Vom Pilot in den Regelbetrieb

Fällt die Entscheidung für die Ausweitung, beginnt der Teil der Einführung, der über die Jahre trägt. Zwei Bausteine machen aus einem erfolgreichen Pilot einen geordneten Regelbetrieb.

KI-Kompetenz und Schulung

Die KI-Verordnung (EU) 2024/1689 verpflichtet Unternehmen seit dem 02.02.2025 zur KI-Kompetenz der Beschäftigten, die KI-Systeme einsetzen (Art. 4). Engineering-Werkzeuge wie Coding-Assistenten sind in der Regel keine Hochrisiko-KI im Sinne von Anhang III; die Einstufung ist dennoch je Anwendung zu prüfen und zu dokumentieren, bevor der Baustein in den Regelbetrieb geht. Inhaltlich heißt Kompetenz hier dreierlei: die Grenzen des Werkzeugs kennen, den Freigabepfad je Tätigkeit kennen und wissen, welcher Code in welche Instanz darf. Eine kurze, wiederkehrende Schulung mit Beispielen aus dem eigenen Pilot leistet dafür mehr als ein einmaliges Rundschreiben.

Betriebsordnung je Baustein

Der Regelbetrieb braucht dieselbe Ordnung wie jedes andere Werkzeug der Toolchain: ein versioniertes Regelwerk, das erlaubte Tätigkeiten, angebundene Repositories und Triage-Klassen festhält, eine benannte Zuständigkeit je Baustein, einen dokumentierten Rückholweg für den Fall, dass eine Instanz oder ein Modellstand ersetzt werden muss, und eine Protokollierung, die im Assessment als Evidenz dient. Der rote Faden bleibt über alle Bausteine derselbe: KI assistiert, der Mensch verantwortet. Eine Einführung, die diesen Satz in Deployment-Entscheidung, Freigabepfad und Pilot-Design übersetzt hat, muss ihn im Regelbetrieb nur noch pflegen.

Nächste Schritte

Welche Deployment-Option, welcher Pilot-Scope und welche Messgrößen zu Ihrem Haus passen, hängt von Kundenauflagen, Toolchain und Teamlage ab und lässt sich nicht aus einem Blogbeitrag ableiten. Der geordnete Einstieg sieht so aus:

1. Überblick lesen: Der Beitrag zu KI in der Automotive-Softwareentwicklung ordnet die Code-Assistenz in die vier Einsatzfelder der Werkzeug-Ebene ein.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus einzelnen Werkzeug-Entscheidungen ein geführtes Transformationsvorhaben wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Ausgangslage, Auflagen und Toolchain Ihres Bereichs zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zur Einführung von KI-Coding-Assistenten in Embedded-Teams zusammen. Sie beschreiben typisierte Vorgehensmuster; wie die Einführung in einem konkreten Haus aussieht, wird je Kunde, Auflagenlage und Toolchain geprüft.

Verlässt unser Quellcode das Haus, wenn wir einen KI-Coding-Assistenten einsetzen?

Nur wenn die Deployment-Entscheidung das ausdrücklich vorsieht. On-Premise-Betrieb hält Modell und Code vollständig im Haus, EU-gehostete dedizierte Instanzen verarbeiten Code extern unter vertraglichem Trainingsausschluss und definierten Löschfristen, SaaS-Dienste mit Enterprise-Vertrag bilden das dritte Modell. Vor dieser Entscheidung und den zugehörigen vertraglichen Zusicherungen darf kein Projektcode in das Werkzeug gelangen.

Welche Deployment-Option passt für Teams mit strengen Vertraulichkeitsauflagen?

Die Option bestimmt sich nach den strengsten Auflagen im Portfolio. Für Code unter besonderen Kundenauflagen oder in einem Rahmen wie TISAX ist On-Premise oder eine dedizierte EU-Instanz mit Audit-Rechten der übliche Weg. Viele Häuser trennen technisch zwischen einer restriktiven Instanz für auflagenbehaftete Projekte und einer komfortableren für eigenen Code.

Gefährdet ein KI-Coding-Assistent das nächste ASPICE-Assessment?

Nicht, wenn der Freigabepfad steht. Assessoren nach Automotive SPICE (ASPICE) bewerten die Erreichung der Prozess-Outcomes; entscheidend ist, dass jeder KI-Vorschlag als Entwurf behandelt wird, Review und statische Analyse verpflichtend bleiben und die Evidenzkette lückenlos dokumentiert ist. Riskant ist der umgekehrte Fall: informelle Nutzung ohne Regelwerk, deren Ergebnisse unmarkiert in Arbeitsprodukte einfließen.

Bleibt die statische Analyse Pflicht, wenn KI den Code vorschlägt?

Ja, ohne Ausnahme. Regelwerke wie MISRA C sind Freigabe-Voraussetzung, und ein Sprachmodell stellt ihre Einhaltung nicht sicher. Tragfähig ist die Kette aus KI-Vorschlag, statischer Analyse gegen das projektspezifische Regelwerk und menschlichem Review; zusätzlich gehört das Werkzeug in die Tool-Vertrauensbetrachtung nach ISO 26262, sobald es sicherheitsrelevante Arbeitsprodukte beeinflusst.

Wie gewinnt man skeptische Entwicklerinnen und Entwickler für einen Pilot?

Mit Freiwilligkeit, offengelegten Messgrößen und einem ausdrücklichen Verzicht auf Personen-Metriken. Die Skepsis erfahrener Embedded-Entwickler ist datengestützt begründet: Laut Stack Overflow Developer Survey 2025 misstrauen 46 % der Entwickler der Genauigkeit von KI-Ausgaben. Eine Einführung, die diese Prüfhaltung als Teil des Freigabepfads einbaut statt sie zu übergehen, gewinnt die kritischen Stimmen als Reviewer des Pilots.

Welche Messgrößen gehören in einen Pilot und welche gehören nicht hinein?

In den Pilot gehören vorab definierte Team-Messgrößen: Durchlaufzeit ausgewählter Aufgabentypen, Review-Befunde je Änderung, Befunde der statischen Analyse und strukturierte Rückmeldung der Teilnehmer. Nicht hinein gehören Auswertungen je Person, Zeilen-Zählungen und Nutzungs-Ranglisten, weil sie den Pilot in ein Überwachungsinstrument verwandeln und die Rückmeldungen entwerten. Abbruchkriterien werden ebenfalls vor dem Start fixiert.

Ist ein KI-Coding-Assistent Hochrisiko-KI im Sinne der KI-Verordnung?

In der Regel nicht. Engineering-Werkzeuge fallen überwiegend in niedrige Risikoklassen der KI-Verordnung (EU) 2024/1689, im Unterschied zu KI-Funktionen im Fahrzeug selbst; die Einstufung ist je Anwendung zu prüfen und zu dokumentieren. Unabhängig davon gilt seit dem 02.02.2025 die Pflicht zur KI-Kompetenz der Beschäftigten nach Art. 4, die eine wiederkehrende Schulung zu Grenzen und Freigabepfad des Werkzeugs sinnvoll macht.