On September 29 in Novi, Michigan, VDA QMC used its NASPICE session to describe what happens to an assessment once AI agents are doing real development work. Their view of the assessor's job came down to a single contrast. Assessors will ask less for "five requirements with traceability" and more for "your AI usage policy, provenance records, and metric calibration approach."
That is a bigger shift than it sounds. For most of its history, passing an Automotive SPICE® assessment has meant producing the right artifacts on demand. The next assessment will ask a team to show how its work was governed while it happened. Most teams can do the first. Very few can do the second.
The standard isn't the problem
VDA QMC was clear that the principles hold. Automotive SPICE® "aims for the What not the How." Consistency, verification and validation, architecture and design, plan-do-check-act. In its summary, VDA QMC said the core principles "are still valid in an AI-centric development."
So agents don't break the standard. They break the way teams prove they met it.
When an engineer writes a requirement, links it to a test and gets it reviewed, the evidence is a by-product of the work. When one agent drafts the requirement, another generates the tests and a person approves both, the work moves faster than the paperwork that used to prove it. VDA QMC named the gap plainly. Nobody really understands what the AI is doing in detail, and collaboration between agents is mostly undefined.
From artifact inspection to governance inspection
VDA QMC describes the assessor role moving "from artifact inspection to governance inspection." Three things take the place of the stack of artifacts.
An AI usage policy. Which agents may act, at which steps of the V-Model, and where a person has to approve. VDA QMC is explicit that governance is not only an organizational policy. It has outcomes at project level, and that is where an assessor will look.
Provenance records. For any work product: who or what produced it, in which version, against which work item, and what happened to it next. A requirement an agent drafted and an engineer reworked twice is different evidence from one that passed review the first time. Today most teams can't tell the two apart.
A metric calibration approach. Which measures the team trusts, what baseline they are held against, and how the team knows the numbers mean what they claim. A metric with no baseline is a number, not evidence.
The purpose of the assessment doesn't change. VDA QMC frames Automotive SPICE® as a tool "to create trust and information for approval." What changes is where the trust comes from.
Evidence moves from documents to metrics
The rest of VDA QMC's thinking points the same way. On consistency, the assessor's question doesn't move: show me evidence that the required consistency has been achieved. The open issue VDA QMC flagged is what that evidence should look like, with a noted "shift towards metrics."
On quality assurance, VDA QMC was blunter. QA shifts to "monitoring metrics instead of checking documentation," and "human-centric bureaucratic approaches will fail."
Here is the practical problem. Most of the evidence already exists. Every state change in the ALM, every commit, every review and every agent session leaves a record. What doesn't exist is the join. Those records sit in separate systems with separate definitions, and nothing ties an action to the process step it belonged to and the outcome that followed.
So teams rebuild that link by hand before each assessment. It was already expensive with people doing the work. With agents in the loop, it stops scaling.
What it looks like in practice
A global Tier 1 automotive supplier runs its development lifecycle in Polarion ALM and Subversion, under the V-Model that ASPICE requires. It had the data. It couldn't see the process. Three BI tools reported defect counts and test coverage, and none of them could explain why the numbers moved.
Bloomfilter turned roughly 7.6 GB of raw operational data per project into 133,729 discrete process events with full V-Model traceability. Three findings came out of the record:
- Regression rework. Regressions made up 72% of the defect count, roughly $963K a year in rework. 18% of stories were bypassing code review, and the bypass rate tracked the regression rate.
- Intake waste. 41% of bug submissions were waste at intake. They fed a 12-day discovery loop in which 80% were eventually cancelled.
- Traceability gaps. Requirements with broken or missing verification chains, the gaps that become critical findings, surfaced months before the scheduled assessment.
The team enforced review gates through process data rather than trust, and the regression ratio began declining within two quarters. It redesigned intake, and the discovery loop dropped by more than 40%. It closed the traceability gaps before the audit.
To improve a process, you first have to understand it. With Bloomfilter, it's like an X-ray. We can finally see what is really happening, based on facts and figures, not opinions.
Head of PMT Software, global Tier 1 automotive supplier
None of that work involved an AI agent. That is the point. The supplier answered the assessor's old question from the record instead of rebuilding it by hand.
The new questions need the same foundation, with agents bound into it as participants in the process. An agent action attributed to a work item and a process step is a provenance record. A grade against the team's own human baseline is a calibrated metric. That is the layer Bloomfilter adds to the process intelligence Celonis customers already use: the development record, and the agents working inside it, in the same process graph.
Before the standard lands
VDA QMC WG13 calls this its "highest priority," with a publication planned for mid-2027. Teams that wait will learn the new questions at their next assessment. Teams that start now can walk in with a record instead of a reconstruction.
Starting doesn't require a new process for engineers or a new tool in the V:
- Instrument what you already log. The ALM, version control and agent sessions already hold the evidence.
- Model the V as it actually runs. Find where evidence is rebuilt by hand before an assessment. That is where the time goes.
- Put agents on the graph before you scale them. Attribute every agent action to a process step from day one, so provenance exists before anyone asks for it.
Probabilistic agents are entering a deterministic assessment. The assessor will ask to see the record. Have one.