K3 und AI: Traceability und Evidenz im ASPICE-Assessment

K3 wird nicht wegautomatisiert: warum Compliance-Arbeit bleibt und trotzdem leichter wird

Kontroll-, Compliance- und Koordinationsarbeit, im Wertbeitrags-Prinzip die Tätigkeitsklasse K3, ist in ASPICE- und ISO-26262-Projekten konstitutiv und verschwindet durch AI nicht. Was sich verändert, ist ihr Zuschnitt: Der Ausführungs- und Logistikanteil, vom Zusammensuchen der Review-Unterlagen bis zum Nachziehen von Trace-Links, wird maschinell vorbereitet. Das Urteil selbst, also Review-Entscheidung, Baseline-Freigabe und CCB-Entscheid, bleibt namentlich beim Menschen.

Wer in einem ASPICE-Projekt Verantwortung für Qualität oder Prozesse trägt, kennt beide Erzählungen. Die eine verspricht, AI schaffe die Compliance-Arbeit ab, endlich müsse niemand mehr Trace-Links pflegen. Die andere warnt, AI gefährde das Assessment, weil Maschinen keine Evidenz verantworten können. Beide Erzählungen scheitern am selben Punkt: Sie behandeln die Compliance-Arbeit als einen Block, statt sie zu zerlegen.

Dieser Beitrag arbeitet die Gegenthese aus dem Wertbeitrags-Prinzip für das Automotive Software Engineering aus: Er zeigt, warum K3 in dieser Domäne Struktur ist und kein Rand, was Assessoren tatsächlich bewerten, wie die Zerlegung am Beispiel der Traceability konkret aussieht und woran sich die Grenze zwischen maschineller Vorbereitung und menschlichem Urteil festmacht.

Warum K3 im ASPICE-Projekt Struktur ist, kein Rand

In generischen Betrachtungen des Arbeitsalltags ist Kontroll- und Compliance-Arbeit die kleinste Tätigkeitsklasse, ein schmaler Rand aus Freigaben und Pflichtdokumentation. In Projekten nach Automotive SPICE (ASPICE) und ISO 26262 kehrt sich das Bild um: Diese Klasse ist normativ gefordert und strukturell groß, und wer sie pauschal als Ballast behandelt, verfehlt die Realität der Domäne.

Traceability und Konsistenz sind eigene Base Practices

Automotive SPICE 4.0 verankert bidirektionale Traceability und Konsistenz als eigene Base Practices in jedem Engineering-Prozess, und die Output-Items der Prozesse heißen ausdrücklich Evidences. Dazu kommen Reviews, Baselines, die Freigaben im Change Control Board (CCB), die geforderte Unabhängigkeit der Qualitätssicherung und die Assessment-Vorbereitung selbst. Nichts davon ist optional, nichts davon lässt sich abwählen, ohne die Bewertungsfähigkeit des Prozesses zu beschädigen.

Der Nachweis ist messbar schwer

Wie schwer diese Arbeit in der Praxis wiegt, zeigt eine Zahl mit klarer Quellen-Einordnung: In der Erhebung von Perforce geben 46 % der befragten Automotive-Teams an (Erhebungsjahr 2025), Schwierigkeiten zu haben, die Einhaltung der ISO 26262 nachzuweisen (Quelle: Perforce, State of Automotive Software Development 2025; Selbstauskunft der Befragten, keine Messung). Die Zahl belegt keine Ursache und keinen Einsparwert. Sie belegt, dass der Evidenz-Nachweis für einen erheblichen Teil der Branche ein reales, selbst berichtetes Problem ist.

Was Assessoren wirklich bewerten

Ein verbreitetes Missverständnis lautet, im Assessment würden Dokumente gezählt: Wer alle Work Products und Trace-Links vorweisen kann, besteht. Dieses Bild ist falsch, und es führt zu genau der Automatisierung, die im Assessment scheitert.

Outcomes und Capability, nicht Dokument-Existenz

Assessoren bewerten nach der Logik der ISO/IEC-330xx-Reihe die Erreichung der Prozess-Outcomes und die Capability-Attribute des Prozesses. Work Products und Evidences sind Indikatoren dafür, kein Selbstzweck. Die Existenz von Dokumenten oder Trace-Links genügt nicht, die inhaltliche Konsistenz zählt, und mangelnde Konsistenz ist ein dokumentiertes Downrating-Thema. Ein Projekt kann eine formal lückenlose Traceability-Matrix vorlegen und trotzdem herabgestuft werden, wenn die Links inhaltlich nicht tragen.

Die Konsequenz für jeden AI-Baustein

Aus diesem Assessment-Bild folgt eine harte Anforderung an jede Automatisierung im Evidenz-Umfeld: Ein AI-Baustein, der die formale Quote erhöht und die inhaltliche Konsistenz senkt, verschlechtert die Assessment-Position, statt sie zu verbessern. Genau diese Lücke, hohe formale Abdeckung bei sinkender inhaltlicher Qualität, ist es, die erfahrene Assessoren finden. Warum manuelle Trace-Pflege einen stillen Zweitnutzen hat und wie man ihn beim Automatisieren erhält, vertieft der Beitrag zur Nebenwert-Prüfung vor jedem AI-Baustein.

Begriffsdisziplin: Overload ist nicht unnötige Arbeit

Bevor die Zerlegung trägt, braucht es einen sauber definierten Begriff. Im Wertbeitrags-Prinzip bezeichnet Overload den automatisierbaren Ausführungs- und Logistikanteil einer Tätigkeit, und ausdrücklich nicht unnötige Arbeit und nicht alles außer dem Kern.

Die Unterscheidung ist mehr als Wortklauberei. Normativ geforderte Tätigkeiten wie Statusberichte, Backup-Verifikation oder Modifikationskontrolle sind Prozesswert; klassifiziert wird ausschließlich ihr mechanischer Anteil. Dafür wird jede Tätigkeit in drei Anteile zerlegt: den Design- und Urteilsanteil, den Implementierungs- und Ausführungsanteil und den Dokumentations- und Logistikanteil. Nur nachweislich regelgebundene Anteile gelten als wiederholbare Betriebsarbeit. Wer dagegen ganze Tätigkeiten als „Ballast“ etikettiert, erklärt implizit Pflichtarbeit zur Verschwendung und verliert die Belegschaft, deren Arbeit er gerade bewertet.

Das Traceability-Beispiel: Urteil und Link-Logistik

Am Beispiel der Traceability lässt sich die Zerlegung vollständig durchspielen, und mit ihr die Grenze zwischen dem, was AI vorbereiten darf, und dem, was beim Menschen bleibt. Das Beispiel ist bewusst gewählt, denn kaum eine Tätigkeit wird in Automatisierungs-Diskussionen so oft als Block behandelt wie die Pflege von Trace-Links.

Die Zerlegung im Detail

Die inhaltliche Konsistenz-Entscheidung, dass eine Anforderung durch bestimmte Verifikationsmaßnahmen abgedeckt ist, ist Entscheidungs- und Kontrollarbeit, also K2 und K3. Das Anlegen, Nachziehen und Reparieren der Links nach jeder Änderung ist wiederholbare Betriebsarbeit, also K4. Dieselbe Tätigkeit, die im Organigramm als „Traceability pflegen“ erscheint, zerfällt bei genauem Hinsehen in ein Urteil, das Verantwortung braucht, und eine Logistik, die Zeit frisst.

Wo der Commit-Punkt liegt

Entscheidend ist der Commit-Punkt, also die Stelle, an der ein Arbeitsstand in das führende System übergeht. Trace-Link-Vorschläge erzeugen einen Arbeitsstand und sind deshalb in der Triage des Wertbeitrags-Prinzips Klasse A2: Das System schreibt in Entwurfsbereiche, die Übernahme in den führenden Stand ist der menschliche Prüfschritt, jeder Einzelfall wird bestätigt. Rein mechanische Übertragung bereits menschlich bestätigter Zuordnungen kann dagegen im Hintergrund laufen, mit lückenloser Protokollierung und dokumentiertem Rückholweg. Die vollständige Klassenlogik mit den Abgrenzungsregeln steht im Beitrag zur Dreifach-Triage für Engineering-Arbeit.

Was „leichter“ konkret heißt

Die These „K3 bleibt und wird leichter“ wird erst belastbar, wenn man benennt, was sich im Alltag der Rollen tatsächlich verändert, vom Review über die Baseline-Freigabe bis zur Assessment-Vorbereitung. Drei Verschiebungen tragen den Unterschied, und keine davon verschiebt Verantwortung von Menschen auf Systeme.

Erstens verschiebt sich die Zeitverwendung innerhalb der Rolle: Der Reviewer erhält ein vorbereitetes Paket mit Diff seit der letzten Baseline, offenen Findings und Checklisten-Vorbefund, statt die Unterlagen zusammenzusuchen; seine Zeit gehört dem Urteil. Zweitens bleibt die Verantwortungskette unverändert: Review-Urteil, Baseline-Freigabe und CCB-Entscheid tragen weiterhin einen Namen, und jeder Baustein protokolliert selbst nachvollziehbar, wer was wann übernommen hat, damit die Prozess-Evidenz assessierbar bleibt. Drittens wird die Konsistenz-Sicherung aktiv gestaltet statt stillschweigend vorausgesetzt: Bestätigungspflicht je Einzelfall und Stichproben-Reviews erhalten das Anforderungs-Lesen, das die manuelle Link-Pflege bisher erzwungen hat.

Ehrlich gehört dazu: Einen belastbaren Prozentwert, wie viel Evidenz-Aufwand sich je Rolle einsparen lässt, gibt es vorab nicht. Verfügbare Zahlen sind Größenordnungs-Belege aus anderen Kontexten, und die Antwort für ein konkretes Haus entsteht in der Analyse, die das Wertbeitrags-Prinzip dafür vorsieht.

Nächste Schritte

Dieses Stück ist die These, nicht das Angebot. Wer den Gesamtrahmen nachlesen will, in dem die K3-These steht, findet ihn im Pillar-Beitrag zum Wertbeitrags-Prinzip im Automotive Software Engineering, einschließlich Tätigkeitsklassen, Wertströmen, Triage und der Grenzen des Modells.

Wer vor einem konkreten Assessment steht und die Evidenz- und Traceability-Arbeit im eigenen Projekt strukturiert entlasten will, findet auf der Seite ASPICE-Evidenz und Traceability mit AI die Beschreibung, wie sensified aus dieser These ein Vorgehen macht: maschinell vorbereitete Trace-Vorschläge, Review-Pakete und Konsistenz-Sichten, mit dem Urteil namentlich beim Menschen und dem ALM-System als unverändertem System of Record.

Häufige Fragen

Kann AI Trace-Links automatisch ziehen?

Vorschlagen ja, eigenmächtig setzen nein. Trace-Link-Vorschläge erzeugen einen Arbeitsstand und laufen deshalb mit Einzelfall-Prüfpunkt: Das System schreibt in Entwurfsbereiche, ein Mensch prüft und übernimmt jeden Link, erst diese Übernahme gibt dem Link den Status im führenden System. Rein mechanisches Nachziehen bereits bestätigter Zuordnungen kann mit Protokoll und Rückholweg im Hintergrund laufen.

Wird die Traceability-Pflege durch AI im Assessment angreifbar?

Nicht, wenn die Verantwortungskette steht. Assessoren bewerten Prozess-Outcomes und Capability-Attribute, Work Products sind Indikatoren. Solange jedes Urteil namentlich beim Menschen liegt, jeder Baustein nachvollziehbar protokolliert und die inhaltliche Konsistenz durch Bestätigungspflicht und Stichproben gesichert wird, bleibt die Evidenzkette assessierbar. Angreifbar wird, wer formale Quoten steigert und Konsistenz verfallen lässt.

Was bedeutet die Tätigkeitsklasse K3 genau?

K3 umfasst Kontroll-, Compliance- und Koordinationsarbeit: Traceability und Konsistenz, Evidences, Reviews, Baselines, CCB-Freigaben, die Unabhängigkeit der Qualitätssicherung und die Assessment-Vorbereitung. Im ASPICE-Umfeld ist diese Klasse normativ verankert und strukturell groß. Das Wertbeitrags-Prinzip zerlegt sie in den Urteilsanteil, der beim Menschen bleibt, und den Ausführungsanteil, der maschinell vorbereitet werden darf.

Was sagt die Perforce-Zahl von 46 % aus, und was nicht?

Sie stammt aus der Perforce-Erhebung 2025 zur Automotive-Softwareentwicklung und besagt, dass 46 % der befragten Teams nach eigener Auskunft Schwierigkeiten haben, ISO-26262-Compliance nachzuweisen. Es ist eine Selbstauskunft, keine Messung. Sie belegt die Größenordnung des Nachweis-Problems in der Branche, aber weder eine Ursache noch einen bestimmten Einsparwert für ein einzelnes Haus.

Verändert Automotive SPICE 4.0 die Bedeutung der Traceability?

ASPICE 4.0 verankert bidirektionale Traceability und Konsistenz als eigene Base Practices in jedem Engineering-Prozess und benennt Output-Items ausdrücklich als Evidences. Damit ist die Evidenz-Arbeit klar sichtbarer Teil des Prozessmodells. Für Häuser mit 3.1-Assessment wird der Unterschied je betroffenem Prozess über einen dokumentierten Abgleich behandelt, bevor Bausteine geplant werden.

Bleibt unser ALM-System führend, wenn AI-Bausteine dazukommen?

Ja, das ist eine Grundregel der Triage: Führende Systeme bleiben System of Record. Augmentations-Sichten lesen ausschließlich, vorbereitende Bausteine schreiben nur in Entwurfsbereiche, und Hintergrund-Automatisierung schreibt nur mit versioniert freigegebenem Regelwerk, lückenlosem Protokoll und dokumentiertem Rückholweg. Die Struktur in Polarion, codebeamer oder Jira wird nicht ersetzt, sondern beliefert.

Hinweis zu AI-Inhalten gemäß EU AI Act Art. 50: Texte auf dieser Seite wurden teilweise mit Unterstützung Künstlicher Intelligenz erstellt.

Die Grundsatzfrage, welche Entscheidungen AI im ASPICE-Prozess grundsätzlich nicht trifft, behandelt der Beitrag Was AI im ASPICE-Prozess nicht entscheidet.

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.