AI-Triage im Engineering: Automatisierung bis Augmentation

Automatisierung, Augmentation, autonome Fallabwicklung: welche AI-Klasse welche Engineering-Arbeit tragen darf

Ob ein AI-Baustein im Automotive Software Engineering zulässig ist, entscheidet sich an vier Prüfdimensionen: Wer entscheidet den Einzelfall, verändert das Ergebnis einen freigabepflichtigen Work-Product-Stand, wie granular ist die Freigabe, und schreibt das System in führende Systeme. Daraus ergeben sich vier Klassen: A1 (Hintergrund-Automatisierung), A2 (vorbereitende Automatisierung mit Einzelfall-Prüfpunkt), B (Augmentation) und C (autonome Fallabwicklung, grundsätzlich nur Prüfkandidat).

Kaum eine Frage wird in Engineering-Organisationen so unscharf diskutiert wie die, was Künstliche Intelligenz (AI) im Prozess übernehmen darf. Begriffe wie Automatisierung, Assistenz und Agent werden gemischt, und am Ende entscheidet oft das Werkzeug-Label statt der Arbeitsinhalt. Dieser Beitrag beschreibt eine Triage-Logik, die auf Prüfdimensionen statt auf Technologie-Etiketten baut. Sie stammt aus dem Vorgehensmodell, das der Leitfaden zum Wertbeitrags-Prinzip im Automotive Software Engineering im Zusammenhang beschreibt, und richtet sich an Engineering-Leitung, Qualitätssicherung und Functional-Safety-Verantwortliche im Umfeld von Automotive SPICE (ASPICE) und ISO 26262.

Vier Prüfdimensionen statt Technologie-Labels

Die Klassen der Triage sind über vier Dimensionen definiert. Das ist die entscheidende Design-Entscheidung im Vorgehensmodell von sensified: Ein Baustein wird danach eingeordnet, wie er in den Prozess eingreift, und danach, welches Modell oder welches Produkt dahintersteht, gerade nicht.

Die vierte Dimension verdient besondere Aufmerksamkeit. Ohne die Angabe, welches System führend ist, wo der Commit-Punkt liegt und ob es einen Rückholweg gibt, ist keine seriöse Klassen-Zuordnung möglich. Deshalb ist die Source-of-Truth-Angabe im Vorgehensmodell Pflichtfeld vor jedem Triage-Vorschlag.

Die vier Klassen A1, A2, B und C

Aus den vier Prüfdimensionen leitet sensified vier Klassen ab, die jede AI-Intervention eindeutig einordnen: zwei Automatisierungs-Klassen, eine Augmentations-Klasse und eine Klasse für autonome Fallabwicklung. Die Tabelle zeigt je Klasse die Definition und die Ausprägung der vier Dimensionen; sie ist das Referenzstück für alle Triage-Entscheidungen in der späteren Entscheidungsmatrix.

Typische A1-Kandidaten sind Daten-Synchronisation über Tool-Brüche, Status-Aggregation für Berichte oder die Provisionierung von Testumgebungen nach versionierten Definitionen. Typische A2-Kandidaten sind Trace-Link-Vorschläge, Testfall-Entwürfe, Finding-Vorsortierung und Coding-Assistenz. B-Sichten bereiten Entscheidungen vor, etwa ein Impact-Dossier je Change Request (CR) oder ein Release-Readiness-Cockpit. Wo diese Kandidaten in den Arbeitsströmen eines Projekts liegen, zeigt der Beitrag zu den vier Wertströmen eines Automotive-SWE-Projekts.

Die vier Abgrenzungsregeln für Grenzfälle

In der Praxis entscheiden sich die meisten Streitfälle an vier Regeln, die sensified als feste Bestandteile der Triage dokumentiert. Sie sorgen dafür, dass zwei Analysten denselben Grenzfall gleich einordnen und dass die Zuordnung im Assessment begründbar bleibt, auch wenn der Eintrag Monate später erneut geprüft wird.

Regel 1 und 2: Arbeitsstand und Determinismus

Erstens: Erzeugt das System einen Arbeitsstand, ist der Baustein A2 und nie B. Coding-Assistenz, Testfall-Entwürfe und Trace-Link-Vorschläge erzeugen Entwürfe, die erst durch die menschliche Übernahme den Status eines Arbeitsergebnisses erhalten. B bleibt reiner Sicht und Analyse vorbehalten. Zweitens: Deterministisch-regelgebundene Abläufe ohne Urteilsspielraum sind A1 und nicht C, auch wenn sie autonom laufen. Restore-Proben, regelbasiertes Routing nach fester Tabelle oder Formalprüfungen gegen explizite Kriterien brauchen keine C-Governance. C ist für Fälle reserviert, in denen ein System Interpretationsspielraum autonom ausübt.

Regel 3 und 4: Rückholweg und Einzelfall-Commit

Drittens: A1 mit Schreibzugriff auf führende Systeme braucht immer einen definierten Rückholweg, etwa Undo oder Quarantäne, plus Protokollierung. Ohne beides ist der Eintrag nicht backlog-fähig. Viertens, die Vorrangregel: Sobald der Ablauf vorsieht, dass ein Mensch jeden erzeugten Stand einzeln prüft und übernimmt, ist der Eintrag A2, unabhängig davon, wie deterministisch die Erzeugung ist. A1 bleibt der regelgebundenen Ausführung vorbehalten, deren Kontrolle über Protokolle, Stichproben oder ohnehin existierende nachgelagerte Prozess-Prüfschritte läuft.

„Klassifiziert wird, wie ein System in den Prozess eingreift. Das Werkzeug-Label spielt für die Zulässigkeit keine Rolle.“

Warum C nur Prüfkandidat ist

Jeder C-Eintrag startet mit dem Status „Prüfkandidat, nicht zulässig“. Das hat drei Gründe. Normativ sind die Evidenz- und Prüfpflichten des ASPICE- und ISO-26262-Umfelds auf menschliche Verantwortungspunkte gebaut; ein C-Baustein muss diese Punkte nachbilden, was den Autonomie-Vorteil oft wieder aufzehrt.

Wie hoch die Evidenz-Last der Domäne ist, zeigt eine Branchenbefragung: 46 % der Automotive-Teams geben laut Perforce-Befragung 2025 an, dass ihnen der Konformitätsnachweis schwerfällt (Quelle: Perforce, State of Automotive Software Development 2025).

Empirisch fand die dokumentierte Recherche hinter dem Vorgehensmodell keinen belastbaren Nachweis zuverlässiger autonomer Ende-zu-Ende-Abwicklung im Automotive-Engineering; die belegten Erfolge liegen bei vorbereitender Generierung mit Prüfung, also A2. Ökonomisch liegt der Hebel ohnehin in A und B, weil die dokumentierte Betriebslast überwiegend aus Datenlogistik und Vorbereitungsarbeit besteht.

Zulässig wird ein C-Kandidat erst über einen dokumentierten Hochstufungspfad: ein Pilot im A2-Modus mit Einzelfall-Prüfung, dessen Messergebnisse, etwa die Trefferquote gegen menschliche Referenz-Urteile einschließlich der übersehenen kritischen Fälle, die Hochstufung begründen. Dazu kommen Nachweise zu Schadensbegrenzung, Normverträglichkeit, menschlichem Freigabepunkt, Betriebsmodell mit Abschaltbarkeit sowie Betriebsrats- und Datenschutz-Verträglichkeit. Diese C-Governance ist teuer, und genau deshalb wird sie nur dort bezahlt, wo sie nötig ist.

Die Konfliktregel: Entscheidungslogik statt Rangfolge

Die Klassen sind nicht ordinal vergleichbar: Ein A1-Baustein mit Schreibzugriff kann riskanter sein als ein A2-Baustein mit Einzelfall-Prüfung. Bei unklarer Zuordnung gilt deshalb eine Entscheidungsregel entlang der vier Dimensionen, die das Vertrauen in die Einordnung unabhängig von Bauchgefühl und Werkzeug-Marketing macht.

A1 setzt vollständig deterministische, versionierte Regeln voraus; ist der Ablauf nicht restlos regelgebunden, wird der Eintrag A2. Bei Interpretationsspielraum oder unklarer Work-Product-Wirkung gilt A2, nie A1 und nie C. B gilt nur bei rein informativer, lesender Ausgabe; sobald ein Arbeitsstand erzeugt oder geschrieben wird, ist der Eintrag A2 oder A1. Und C ist nur über den dokumentierten Hochstufungspfad erreichbar, nie als Erst-Zuordnung.

Eine spätere Höherstufung, etwa von A2 nach A1 nach belegter Determinisierung, ist dabei ein normaler Lernpfad im Betrieb und keine Niederlage der Analyse. Jede Konflikt-Entscheidung wird im zugehörigen Matrix-Eintrag mit einem Satz begründet; wie diese Einträge aufgebaut sind, beschreibt der Beitrag zur Entscheidungsmatrix und ihrem Weg ins Backlog.

Nächste Schritte

Die Triage ist der Mittelteil einer Kette: Vor ihr liegen Wertstrom-Begehung und Rollen-Interviews, nach ihr die Härtung der priorisierten Kandidaten. Den Gesamtzusammenhang ordnet der Leitfaden zum Wertbeitrags-Prinzip im Automotive Software Engineering; sensified führt die Klassifikation intern durch und validiert sie gemeinsam mit den Fachrollen des Kunden.

Wer die Triage auf das eigene Projekt anwenden will, findet im Wertbeitrags-Audit für Automotive Software Engineering den strukturierten Weg dorthin: von der Erhebung über die klassifizierte Entscheidungsmatrix bis zu übergabefähigen Backlog-Einträgen. Der Einstieg ist ein Qualifying-Call, den Sie über die Audit-Seite als Termin buchen können.

Häufige Fragen

Ist Coding-Assistenz Automatisierung oder Augmentation?

Weder reine Automatisierung noch Augmentation: Coding-Assistenz ist A2, vorbereitende Automatisierung mit Einzelfall-Prüfpunkt. Sie erzeugt Code-Entwürfe, also Arbeitsstände, und fällt damit nach Abgrenzungsregel 1 aus der Klasse B heraus. Der Entwickler prüft und übernimmt jeden Vorschlag einzeln; erst diese Übernahme macht den Entwurf zum Arbeitsergebnis. Das menschliche Urteil bleibt vollständig erhalten.

Was unterscheidet A1 von A2?

A1 führt regelgebundene Arbeit ohne Urteilsspielraum aus und wird über Protokolle und Stichproben kontrolliert. A2 erzeugt Entwürfe oder Vorschläge, die ein Mensch in jedem Einzelfall prüft und übernimmt. Die Vorrangregel entscheidet Grenzfälle: Sobald ein Einzelfall-Commit durch einen Menschen vorgesehen ist, gilt A2, unabhängig davon, wie deterministisch die Erzeugung arbeitet.

Warum ist Klasse C zunächst nicht zulässig?

Weil für autonome Ende-zu-Ende-Abwicklung im Automotive-Engineering in der dokumentierten Recherche kein belastbarer Qualitätsnachweis gefunden wurde und die Evidenzpflichten der Domäne auf menschliche Verantwortungspunkte gebaut sind. Ein C-Kandidat wird erst zulässig, wenn ein Pilot im A2-Modus seine Qualität gegen menschliche Referenz-Urteile belegt und die weiteren Nachweise bis hin zu Betriebsmodell und Abschaltbarkeit vorliegen.

Darf ein AI-System in Polarion, Jira oder Git schreiben?

Nur unter definierten Bedingungen. A1-Bausteine dürfen in führende Systeme schreiben, wenn ein dokumentierter Rückholweg und lückenlose Protokollierung existieren. A2-Bausteine schreiben nur in Entwurfs- und Arbeitsbereiche; die Übernahme in den führenden Stand bleibt der menschliche Prüfschritt. B-Sichten haben grundsätzlich keinen Schreibzugriff. Die Source-of-Truth-Angabe ist deshalb Pflichtfeld vor jeder Zuordnung.

Was passiert bei einer unklaren Zuordnung?

Dann greift die Konfliktregel entlang der vier Prüfdimensionen: Im Zweifel wird die Klasse mit Einzelfall-Prüfung gewählt, also A2. Eine spätere Höherstufung nach belegter Determinisierung oder nach erfolgreichem Pilotbetrieb ist ein normaler Lernpfad. Jede Konflikt-Entscheidung wird im Matrix-Eintrag kurz begründet, damit sie im Assessment und im Betrieb nachvollziehbar bleibt.

Gilt die Triage auch für Safety-Software nach ISO 26262?

Ja, mit zusätzlichen Auflagen. Für Bausteine, die Work Products safety-relevanter Software erzeugen oder prüfen, wird eine Tool-Confidence-Betrachtung je Verwendungsfall und Fehlermodus vorbereitet. Die Einstufung bestätigt der Safety-Verantwortliche des Kunden; bis dahin gilt sie als offene Annahme mit Owner und Frist. Solche Einordnungen sind Arbeitshypothesen und werden vor dem Einsatz von den zuständigen Rollen geprüft.

Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema.