Automating ASPICE Work Product Reviews With AI: How AutoAssessPro.AI Gets You to 100% Coverage

If your ASPICE assessment always seems to arrive as a surprise, you’re not alone — and it’s not because your engineers aren’t doing the work.

It’s because most teams only find out how they’re really doing when a formal assessor shows up, weeks or months after the work is done, sampling a slice of the requirements, architecture, and test records and hoping it’s representative. Manual reviews like that are typically only 70–80% effective, which means a real, non-trivial share of issues simply never surface until it’s expensive to fix them.

Automotive SPICE (ASPICE) itself hasn’t gotten any easier to satisfy, either. Launch timelines have compressed dramatically — a decade ago, a one-year vehicle program would have sounded unrealistic; today, especially for EV programs, it’s normal. Global teams are split across sites. Systems, software, and hardware engineering have to stay in sync, often without a dedicated systems engineer tying it all together. And ASPICE, functional safety, and cybersecurity requirements all have to be met at the same time, on the same schedule.

Omnex has spent decades helping automotive and semiconductor organizations build compliant, well-run development programs — assessing, training, and consulting against ISO 26262, Automotive SPICE, and ISO/SAE 21434. In a recent webinar, Nikhil Unnikrishnan, Director of Consulting at Omnex, walked through how AutoAssessPro.AI is changing that picture: connecting directly to the repositories your team already works in, running continuous AI-powered checks against ASPICE criteria, and giving you a realistic read on your program’s readiness in about 45 minutes — well before a formal assessment ever begins. Here’s what that looks like in practice, and what it found on a real OEM program.

Why ASPICE Reviews Are Getting Harder to Keep Up With

The pain isn’t new, but a few forces are making it worse at the same time:

• Systems engineering integration is a common gap. Model-based systems engineering (MBSE) adoption is growing among OEMs and Tier 1s, but many organizations still lack a dedicated systems engineer to tie systems, software, and hardware disciplines together at the system, subsystem, or component level.
• Manual assessments don’t scale. They rely on heavy manual effort and limited sampling, which produces inconsistent insight — and typical manual inspections are only about 70–80% effective, leaving real room for issues to slip through.
• Launch timelines have compressed. New vehicle programs, especially EVs, now run on runways that would have seemed unrealistic a decade ago — so teams have to develop products well AND faster, at the same time.
• Globalization adds coordination overhead. Work teams split across regions and time zones need to collaborate on the same requirements, architecture, and test artifacts without losing consistency.
• Multiple frameworks, one timeline. Meeting ASPICE, functional safety, and cybersecurity requirements simultaneously — while still satisfying diverse customer requirements — stretches quality teams thin.

The most common real-world failure pattern Nikhil described is simple: a team gets pulled in at the last minute for an assessment, without having followed the right process consistently along the way, and the results reflect it. Teams that set up their processes early and follow them through development have a much higher chance of a good ASPICE assessment score — the challenge has always been knowing where you actually stand before that formal assessment happens.

How AutoAssessPro.AI Actually Works

AutoAssessPro.AI is one capability of OBOT, the Omnex bot engine. It connects to your live repositories through a proprietary connector called NetSync, which extracts information directly from those systems — project strategies, schedule and review records, requirements, architecture, test cases, test records, change requests, problem records, and more — and processes it against ASPICE compliance criteria using AI. Because it’s reading from your actual, current repositories, you’re not reviewing a stale snapshot; you’re seeing where things stand right now.

In the webinar demo, Nikhil set up a fictitious “Mercury battery pack” program as a new assessment event, connected it to the relevant tool chains, and ran it. What came back wasn’t a single pass/fail number — it was live indicators across ASPICE process areas: system processes, software processes, support, management, and more. Rather than waiting weeks for a full formal assessment with a room full of stakeholders, this “semi-assessment” surfaces where the weak points are in near real time.

Quantitative checks: catching structural problems

Take SYS.2 (System Requirements Analysis). Each ASPICE process has base practices — the things a process must meet under the model — and those decompose into detailed criteria and rules that check specific pieces of information. In the demo, one rule flagged cases where too many system requirements were traced back to a single stakeholder requirement, a classic one-to-many over-decomposition problem. With a threshold set, the tool returned 12 findings that exceeded it, and clicking through showed the exact list of over-decomposed requirements — not just a count.

Qualitative checks: catching writing-quality problems too

Quantitative checks are only half the picture. AutoAssessPro.AI also evaluates whether functional and non-functional requirements are actually well-written — whether they violate the basic rules of what a “good requirement” looks like. In one example from the demo, roughly 800 requirement samples were evaluated, and about 226 of them were flagged as inadequate. That’s the kind of judgment a human reviewer normally has to make one requirement at a time; AutoAssessPro.AI approximates it at scale, across the full sample rather than a hand-picked slice.

From Findings to Ratings — and Real Action Plans

Findings roll up to base-practice-level ratings using the familiar ASPICE scale: N/P/L/F (Not achieved / Partial / Largely / Fully achieved), calculated from sample size and number of findings, with some rules weighted more heavily than others depending on their importance. Process teams can then consolidate those findings into action plans — for example, feeding them into a problem-resolution process.

AutoAssessPro.AI can also evaluate a process strategy document itself. Upload a strategy for a process like problem-resolution management (SUP.9), and the bot analyzes it — using natural language processing and LLMs to parse documents that often contain images and tables — against what ASPICE and best-in-class industry practice expect, plus your own internal criteria, showing what’s covered and what gaps remain.

It goes a step further by comparing what a strategy document says against what’s actually implemented in your tools. If a documented workflow describes one process but your change-tracking tool is configured differently, that’s a real deviation, and it gets flagged — not just a traceability gap, but an actual inconsistency between what you say you do and what you do.

Beyond traceability: checking for true consistency

Some tools already track traceability between requirements and test cases. AutoAssessPro.AI checks something harder to catch: consistency. A requirement might reference one specification while its linked test case actually checks against something different — the link exists, so it’s technically traceable, but it isn’t consistent. The same principle applies to architecture: the tool compares system and software architecture elements against the architecture descriptions and diagrams that document them, and checks whether the software elements used in the architecture match the software elements used for requirements allocation. Mismatches on either front get flagged as deviations.

A Real Program, By the Numbers: 100% Coverage in 7% of the Time

Nikhil shared results from a real OEM program run through the tool — referred to as “Project X” to keep the program confidential. Work products were evaluated across multiple ASPICE processes: problem resolution, change request, project management, requirements analysis, and more, with each process area showing how many work products from it had been reviewed.

The findings were concrete, not abstract: incomplete defect descriptions, impact analysis, root cause analysis, and consequence-of-defect fields; missing impact analysis and risk-from-changes analysis; effort-estimation inefficiencies; inconsistencies in system requirements discussions and verification criteria; incomplete verification reviews; unapproved architecture still in use during test execution; and missing test coverage for some key system-level requirements.

• 1

  100% review coverage in roughly 7% of the time a manual review would take — meaning roughly 93% of review time was saved, according to the time study Nikhil presented, while still identifying more findings, and identifying them earlier in the development process.

And the earlier those findings surface, the more they’re worth. Nikhil cited European OEM studies indicating that issues are roughly ten times cheaper to fix when they’re caught in earlier development stages than when they’re caught later — which is exactly what a continuous, AI-assisted review makes possible, since it’s checking work products as they’re created rather than waiting for a milestone review.

AI That Keeps Learning — With a Human Always in the Loop

AutoAssessPro.AI isn’t presented as a black box, and Nikhil was direct about its limits: AI tools aren’t 100% accurate. When a user spots a discrepancy between what the bot flagged and what it should have found, they can submit a “training request.” A process expert — for example, a senior systems engineer who effectively sets the “golden standard” for what good and bad look like — reviews that request and can accept or reject it. If accepted, the AI agent learns from it and updates its classification going forward; if rejected, the rejection is simply recorded.

Nikhil gave a concrete example: a consistency issue was found between software architecture and integration test cases, and the tool was retrained with labeled consistent and inconsistent examples so its consistency checks between the two improved over time. The result is a system that retains lessons learned, keeps getting more accurate, and keeps a human decision-maker in the loop for trust and verification at every step — the same design principle Omnex applies across its other AI tools.

What This Actually Buys Your Team

• 1

  Assessment readiness, without guesswork — team members often know their internal processes well but not every detail of ASPICE itself, which creates uncertainty about hidden gaps. Broader review coverage and sampling builds real confidence before the formal event.

• 2

  Qualitative insight at scale — not just pass/fail counts, but the kind of writing-quality and consistency judgment a human reviewer makes, applied across your full set of work products instead of a sample.

• 3

  Full review coverage without reviewer fatigue — every work product can be checked, freeing your senior people from repetitive manual review so they can spend time on higher-value decisions.

• 4

  Speed — a semi-assessment runs in about 45 minutes with far less human involvement than a formal assessment. It’s explicitly not a replacement for that formal assessment; it’s preparation for it, and an assistant to your existing quality team.

• 5

  Earlier detection — catching issues before requirements, architecture, test cases, and execution are all “done” is dramatically cheaper than catching them afterward.

Related AI Capabilities From Omnex

AutoAssessPro.AI is part of a broader set of Omnex AI tools built on the same OBOT engine, including FMEA recommendation systems that flag discrepancies in design and process FMEAs, requirements-management AI that extracts and generates requirements from customer PDFs in context with your existing system-level requirements, problem-solving AI that validates the quality of root causes and problem descriptions, and PPAP review AI that checks documents at PPAP maturity and generates findings.

Frequently Asked Questions