Controlled AI that speeds automotive requirements work by about 3x.
Developed for a global automotive manufacturer, rinf.tech built an AI system that analyses safety-critical requirements, maps them to the applicable regulations, and drafts the test criteria. It runs on the manufacturer’s own infrastructure, which avoids the IP exposure of sending protected requirements to a public-cloud AI.
In the demonstration, the work per requirement dropped from 35–55 minutes to about 10, roughly 3x faster, and the answers traced back to their source documents. The system is a validated proof of concept.
Automotive requirements work is one of the largest recurring overheads in a safety programme. A product update means drafting requirements, mapping them to the applicable regulations, validating them, and generating test criteria.
Generic AI did not solve it. The manufacturer had tried off-the-shelf generative AI; the text came faster, but the output still needed manual verification, so the total effort did not move. And because requirements documents are protected IP, they could not be sent to an external system.
rinf.tech built an isolated AI system that runs on the manufacturer’s own infrastructure. It drafts and checks requirements against their source documents, scoring 0.9–1.0 on RAGAS, a standard measure of how faithfully AI output matches its sources, and it runs in the tools engineers already use. The proof of concept was validated in Q2 2026.
Faster per requirement. An engineer spent 35–55 minutes drafting and checking each requirement; the demonstration did it in about 10.
External data egress. The requirements IP was not sent to a cloud service or third-party API; the AI calls ran on the manufacturer’s own infrastructure.
RAGAS source-faithfulness. The answers scored 90% or higher for source-faithfulness, so a reviewer checks a citation instead of re-deriving the answer.
The overhead few teams talk about
In automotive development, requirements set the launch date. A product update triggers the same cycle: requirements are drafted, mapped to the applicable regulations, validated for completeness, and turned into test criteria, line by line. That cycle runs in parallel across the systems, variants, and markets.
At scale, the cost compounds. A new regulatory standard adds another round of cross-checking and mapping across the product line.
The manufacturer had tried off-the-shelf generative AI, with poor results. It produced text fast, but the output was inconsistent and not tied back to the source documents, so a reviewer could not confirm where an answer came from. It still needed manual verification, and the total engineering effort did not change.
An AI system that runs on the manufacturer’s own hardware
By the time the manufacturer brought in a partner, where the system would run was already decided. Public cloud was out because the requirements are proprietary IP that cannot leave. What the manufacturer had was on-premise GPU clusters, inside a network it had spent years getting through compliance. So the task was set before the first conversation, to build the AI on that hardware, inside that network.
rinf.tech built an isolated system that draws answers from the manufacturer’s requirements, without connecting to an external system. The answers trace back to the source documents they came from, scoring 0.9–1.0 for source-faithfulness, and because it runs in the tools engineers already use, it did not change how they work.
# 01 — Ingestion
It accepts requirements in the formats engineers already use. Excel files are parsed, structured, and stored with unique IDs. Existing documentation does not have to be reformatted first.
# 02 — Analysis
Requirements are checked for completeness, ambiguity, and internal consistency. The system flags missing attributes, units, and the responsible subsystem, and drafts structured clarification templates. The depth is configurable, from a gateway-level review to a detailed safety-critical assessment.
# 03 — Regulation mapping
Requirements are cross-referenced against the applicable regulatory standards. The system identifies which regulations a requirement satisfies and flags gaps where more requirements are needed, tracking coverage across the product line.
# 04 — Test criteria
The system drafts test criteria aligned with ASPICE, the automotive software process standard. These are the structured attributes that define what to test and how. They are not full test cases: the test criteria stay the requirements author’s responsibility and set the scope for the test team.
How it was built
Discussions began in November 2025, implementation in January 2026, and the system reached demonstration in May 2026.
The proof of concept ran as a web application. Engineers upload their Excel requirement files through a React interface, and the system parses and structures the data. It then runs the analysis on language models hosted on rinf.tech’s infrastructure, with access restricted by credential, and generates the test criteria and regulation mappings, keeping full version history. The production version would run as a native Excel add-in on the customer’s hardware, with no persistent storage and no external connection.
Governed, reversible, and owned by the client
Before any code, rinf.tech mapped the manufacturer’s existing requirements structures and agreed a shared baseline: how requirements are formatted at the different product levels, which attributes are mandatory, and what the system has to validate across the line. That work produced a requirements framework the manufacturer kept, independent of the engagement.
Reversibility was built into both the process and the system. Phases had a defined rollback procedure, agreed with the client’s governance team before work began and required for sign-off at the gates. In the tool, changes to a requirement or test criterion are versioned, so an edit can be traced and rolled back, and requirement history is not overwritten.
What the demonstration showed
Work per requirement, about 3x faster.
From 35–55 minutes to about 10, measured by the manufacturer’s own system engineers during the demonstration. A demonstration estimate.
The data stayed in the environment.
The AI operations ran on isolated infrastructure, locked to approved users, without a connection to the public internet. Verified by an access-control audit.
Output that traces to its source.
The answers scored 0.9–1.0 for source-faithfulness, so a reviewer checks against the cited source document instead of re-deriving the result. That is what kept review time from rising, the third constraint the manufacturer set.
AI that runs where the IP lives
Most AI tools work in a demonstration. Fewer run on the client’s own infrastructure, with their IP, in their existing workflow, and with output a reviewer can trace to its source. That combination is what controlled AI means, and this proof of concept showed it.
It also leaves something that outlasts the engagement: a requirements framework the manufacturer owns outright, whether it continues with rinf.tech or builds on the work itself. The faster cycle is what the demonstration showed; the framework, and the control around it, are what the manufacturer keeps.
- Industry
- Automotive manufacturing
- Engagement type
- AI requirements automation
- Scope
- Requirements analysis, regulation mapping, ASPICE-aligned test criteria
- Deployment
- Customer-owned infrastructure; no external egress
- Timeline
- Nov 2025 – May 2026 (discussions to demonstration)
- Status
- Proof of concept, validated Q2 2026