Sitz, Platz, Hol: KI für ASPICE trainieren

Wer ASPICE-Assessments durchführt oder daran mitwirkt, sollte skeptisch gegenüber “KI-gestützter Compliance” sein. Große Sprachmodelle (LLMs) sind nicht deterministisch und neigen zu Halluzinationen – das macht die Idee eines vollautonomen KI-Assessors gefährlich. Dennoch eignet sich ASPICE aufgrund seiner strengen, regelbasierten Struktur überraschend gut für KI-Anwendungsfälle. Wir haben unterschiedliche Ansätze ausprobiert und unser finales Framework für unseren ASPICE-Agenten in den folgenden Leitplanken zusammengefasst.

Whitepaper

AI-Assisted ASPICE Compliance

Wie Knowledge Graphs und LLM-Agenten die ASPICE-Prozessbewertung automatisieren: zweistufige Konsistenzprüfung, fünf spezialisierte Agent-Skills und eine Kosten-Nutzen-Analyse für ein Referenzprojekt mit 5.000 Anforderungen.

Kostenlos · PDF · englisch

Whitepaper laden

Packe alles in Skripte, was sich in Skripte packen lässt.

Dies ist im Grunde eine Variante von “verwende das richtige Werkzeug für die richtige Aufgabe”. Es ist verlockend, der KI einfach nur Kontext zu geben und sie mit aufwendigen Prompts zu beauftragen, aber das ist schlichtweg nicht die beste Strategie. Man sollte vielmehr den strengen, regelbasierten Charakter von ASPICE-Prozessbeschreibungen ausnutzen. Jede Metrik oder Regel, die deterministisch definiert werden kann, muss programmiert werden. So stellt man sicher, dass Compliance-Prüfungen auf objektiver, reproduzierbarer Logik basieren und nicht auf probabilistischer Schlussfolgerung.

ASPICE-Beispiel: Der Agent vergibt niemals selbst eine Bewertung: Die N/P/L/F-Skala (siehe Automotive SPICE PAM v4.0 (Table 16 - Rating scale)) ist im Code hinterlegt (0-15 % = nicht erreicht, 16-50 % = teilweise, 51-85 % = weitgehend, 86-100 % = vollständig). Der entsprechende Skill verbietet es dem Modell, die Berechnungen selbst durchzuführen und weist es stattdessen an, immer das Berechnungstool aufzurufen. Das Modell beurteilt, welche Artefakte sich als Nachweis für eine Base Practice eignen; der Code entscheidet über Prozentsätze und Scores.

Speichere Zwischenergebnisse und Fortschritt ab.

Sich auf das KI-Gedächtnis zu verlassen, schafft eine nicht nachvollziehbare “Black Box”. Indem der Agent jeden Schritt in einem strukturierten Audit-Trail (z. B. JSON-Dateien) festhält und Artefakt-Attribute, Modell-Überlegungen oder Zwischenbewertungen protokolliert, verwandelt er probabilistische LLM-Ausgaben in einen transparenten, vollständig überprüfbaren Workflow. Abgesehen von der Auditierbarkeit erlaubt das Speichern des Status außerhalb des Kontextfensters der Pipeline, jederzeit von einem beliebigen Punkt aus fortzufahren oder bestimmte Schritte sauber neu zu bewerten, ohne von vorne anfangen zu müssen.

ASPICE-Beispiel: Der Agent zeichnet jede Base Practice mit ihren Artefakten, den Lücken und dem Teilergebnis jedes Checks auf, zusammen mit der Gewichtung des Teilergebnisses. So lässt sich jeder Wert im Abschlussbericht aus den gespeicherten Daten nachvollziehen. Er vermerkt zudem bei jedem Artefakt, ob das verbindlich zu dokumentierende versionssichere Ablagesystem von einem Menschen angegeben oder durch einen Scan erschlossen wurde und schreibt seinen eigenen Fortschritt in eine separate Statusdatei. So setzt ein Durchlauf dort wieder an, wo er unterbrochen wurde und nicht am Anfang.

Nimm Dir nicht zu viel auf einmal vor.

Das gilt im echten Leben wie auch bei KI. Bei einer großen Anzahl von Artefakten und Links - was im ASPICE-Umfeld meist der Fall ist - muss man vermeiden, umfangreiche und komplexe Auswertungen für alle gleichzeitig durchzuführen. Stattdessen sollten sie in handhabbare Teilmengen (Batches) aufgeteilt werden. Im Extremfall: 1 LLM-Aufruf pro Artefakt oder 1 LLM-Aufruf pro Triple (Subjekt, Prädikat, Objekt). Da das Senden eines separaten Prompts für jedes einzelne Artefakt/Triple jedoch das Token-Budget für redundante Systemanweisungen verschwendet und die Ausführungsgeschwindigkeit drosselt, gilt es, das richtige Gleichgewicht zu finden.

ASPICE-Beispiel: Der Agent verarbeitet Artefakte in Batches, sortiert nach ID, sodass die Batch-Grenzen bei jedem Durchlauf an derselben Stelle liegen. Er berechnet die Gesamtsummen erst nach dem letzten Batch, damit keine Kategorie zwischen zwei Batches aufgeteilt wird. Dokumente werden auf dieselbe Weise zerlegt: Der Scanner arbeitet abschnittsweise, anstatt ganze Dateien auf einmal zu erfassen und eine abschließende Zählprüfung fängt jeden Batch ab, der nicht verarbeitet wurde.

Stell keine offenen Fragen.

LLMs sind darauf trainiert, “behilflich” zu sein, weshalb sie dazu neigen, sehr detaillierte und umfassende Antworten zu geben. Genau das muss man unterbinden. Nicht nur durch das übliche “Bitte eine kurze Antwort.”, sondern durch das Erzwingen von Entscheidungen. Die erlaubten Antworten müssen nach Möglichkeit auf binäre Antworten beschränkt werden, um die Komplexität zu reduzieren und das Risiko von Halluzinationen erheblich zu senken. Komplexe Fragen lassen sich oft in kleinere Ja/Nein (oder geschlossene) Unterfragen aufteilen, die dann logisch kombiniert werden können, um das gewünschte Ergebnis zu erzielen.

ASPICE-Beispiel: Der Agent wird nie gefragt, ob zwei verknüpfte Anforderungen konsistent sind. Er beantwortet geschlossene Prüfungen in einer festen Reihenfolge und schreibt jede Antwort auf, bevor er weitermacht, z. B.: “Sind Quelle und Ziel in derselben funktionalen Domäne?” - ja oder nein; “Deckt das Ziel alle Aspekte der Quelle ab: vollständig, teilweise oder gar nicht?”; “Spezifizieren beide widersprüchliche Werte?” - ja oder nein. Eine First-Match-Tabelle ordnet diesen Antwortsatz dann genau einem Befundtyp und einer deterministischen Bewertung zu. So wird das Urteil regelbasiert kombiniert, statt vom Modell abgegeben zu werden (siehe erste Leitlinie).

Halte fest, was NICHT getan werden darf.

Man muss dem KI-Modell spezifische Anweisungen in Form von Verboten/negativen Imperativen geben: “Tu dies nicht! Tue niemals das!”, etc. Das Bereitstellen von Kontext, Regeln, Architekturentscheidungen und Zielen sagt dem Modell zwar, was zu tun ist und wie es Schritt für Schritt vorgehen soll. In den meisten Fällen reicht dies jedoch nicht aus, um die dem Modell innewohnende “Kreativität” und seine Neigung, eigene Wege zu gehen, angemessen im Zaum zu halten. Ihm explizit zu sagen, was es – absolut, unter keinen Umständen, niemals – tun darf, hilft.

ASPICE-Beispiel: “Berechne niemals selbst Bewertungen!” (auch hier, siehe erste Leitlinie), “Fülle niemals eine Lücke mit einem plausiblen Wert!” oder, wenn ein Dokument als Beleg zitiert wird, “Zitate niemals vereinfachen, paraphrasieren oder zusammenfassen!”

Im Zweifel: Kennzeichnen.

Wir neigen dazu, an KI höhere Ansprüche zu stellen als an uns selbst, aber ein KI-gestütztes Pre-Assessment erfordert nicht zwingend 100 % Genauigkeit. Es verlangt jedoch eine nahezu perfekte Erkennungsrate, bei der jeder tatsächliche Compliance-Verstoß erfasst wird (null falsch-negative Ergebnisse), selbst wenn dies bedeutet, dass gelegentlich ein Artefakt oder Link gemeldet wird, das eigentlich in Ordnung ist (falsch-positiv). Diese “konservative Voreingenommenheit” ist das Fundament für Vertrauenswürdigkeit.

ASPICE-Beispiel: Der Type Check bietet dem Agenten einen Ausweg, der keine Entscheidung erzwingt: wenn ein Artefakt nicht eindeutig einer Kategorie zugeordnet werden kann, muss er dies angeben, verstärkt durch die Anweisung “Erzwinge niemals eine Einschätzung!” (siehe vorherige Leitlinie). Diese Antwort wird dann an einen Menschen zur Überprüfung weitergeleitet, während eine erzwungene Einschätzung zu einem falschen “bestanden”-Ergebnis führen könnte.

Fazit

Bei der erfolgreichen Integration von KI in die ASPICE-Compliance geht es nicht darum, den Assessor zu ersetzen, sondern darum, ein Framework zu definieren, das die KI in sicheren, deterministischen Grenzen hält. Mit der Anwendung der in diesem Artikel vorgeschlagenen Leitplanken konnten wir die Korrektheit und Reproduzierbarkeit der Ergebnisse signifikant verbessern und uns weg von der “Black Box” LLM hin zu einem System bewegen, das transparent, auditierbar und vertrauenswürdig ist.

Wenn man einen KI-Agenten derart stark einschränkt, riskiert man, ihn zum Assistenten zu degradieren. Doch die Leitplanken steuern lediglich, wie der Agent arbeitet, nicht, ob er eigenständig agiert. Er führt das Assessment nach wie vor selbst durch: er steuert die einzelnen Schritte, trägt die Nachweise zusammen, hakt nach, sobald die Daten nicht mehr ausreichen und setzt die Arbeit genau dort fort, wo sie stehen geblieben ist. Aber das finale Ergebnis wird nie vom Agenten festgelegt. Das obliegt immer dem Assessor - der Agent erledigt nur die Arbeit.

Requirements Traceability in der Praxis — Wie durchgängige Traceability in regulierten Projekten wirklich funktioniert, welche Werkzeuge sich bewährt haben und wann der RTM-Ansatz an seine Grenzen stößt: Requirements Traceability bei itemis →