Lesson 12 of 16 · Automation and AI · Automotive SPICE, the vital 20 %
AI-generated work products under assessment
When agents draft the requirements, the code and the tests, what does an assessor look at? The VDA Guidelines answer directly, and the answer is mostly "the same things, plus configuration management of the AI itself".
Which process's base practice notes that a complete, consistent baseline can support a gate approval?
On a project running for a year, a design document first appears in the repo four days before the assessment, with no reason given. The assessor…
Seat-Heat adopts coding agents
What the Guidelines say
The Guidelines' section on AI assistance starts from the WHAT/HOW split: "there is no limitation or recommendation regarding tool usage", and using an AI tool "is a how-level decision". The assessor still rates the WHAT[Guidelines §2.5.5, p. 98]. Their worked example: a developer generates code with an AI tool, reviews it against the detailed design and the coding guidelines, and corrects it. The assessor spot-checks, and "if no deviations are found, there is no negative impact on the rating of process attribute PA1.1 of the SWE.3 process"[p. 98].
Then the warning: AI tools produce "less accurate and sometimes even unusable results … just as often as good ones", so "the assessed organization shall ensure with clear criteria that risks from AI engineering tools will be adequately handled", whether through review, test-driven development or another approach[p. 99]. Among the places it may impact, the Guidelines name SUP.8, SUP.1 and PA 2.2, with examples[p. 99]:
- new configuration items, such as the prompts used to generate source code;
- a maintained list of development tools, including approval of specific AI tools;
- version control of "AI tools, models, and settings, because their behavior changes over time";
- input and output work products of AI assistance under quality control.
Four consequences worth designing for
| Concern | Where ASPICE puts it |
|---|---|
| Reproducibility | Prompts as configuration items; AI tools, models and their settings under version control: SUP.8.BP1–BP4, GP 2.2.3. |
| Clear criteria for AI output | Review and quality criteria (GP 2.2.1), reviews against them (GP 2.2.4); SUP.1.BP2–BP3. |
| Who may approve | ASPICE doesn't name a role. It asks that responsibilities and authorities are defined (GP 2.1.3). For changes, the Guidelines expect the change control board (CCB) to represent all required stakeholders, and its participants to "have the necessary authority to take decisions"[§3.26.2.3, p. 209]. |
| Evidence written after the fact | The plausibility check: work products made shortly before an assessment are not considered, and histories should match the work's rhythm[§1.4.3.2, p. 38]. AI makes it cheap to generate plausible work products late, and an assessor looking at the history will notice. |
Where self-review stops counting. GP 2.2.4 asks for reviews against criteria; its text doesn't demand independent reviewers. Independence is SUP.1's requirement, "no self-monitoring"[p. 79], and the Guidelines' SUP.1 section links it to "the four-eyes principle, such as self-monitoring of the author of a work product is not sufficient"[§3.23, p. 192]. So an agent checking its own output can support a review, but it can never be your quality assurance. Having a different reviewer from the producer is the safe design.
Practice
Seat-Heat doesn't record which model and settings produced a change. Which process does that hit first?
Can AI-written code still leave SWE.3's PA 1.1 unaffected?
An agent writes the missing design documents from the code at release end. The main assessment risk is…
Prompts that generate code are, according to the Guidelines' examples, candidates for…
Can an agent's self-check of its own output count as SUP.1 quality assurance?
List three things Seat-Heat should put under configuration management now that agents write code.
The prompts (or task instructions) that generate work products; the AI tools, models and their versions and settings; and the approved-tool list. Also keep the inputs and outputs of AI assistance under quality control.
Your win: you can set up AI-assisted development so its output is assessable, and you know which of your safeguards are ASPICE demands and which are your own choices.
To keep it: import this lesson's Anki deck (how).
Read next
Guidelines §2.5.5 AI assistance in development, pp. 98–99. It's two pages.
Want to check your own team's AI setup against this? Describe it to your teacher in the chat.