AI Audit Trail for Automotive: UN R155 Forensics Applied to Model Traffic
UN Regulation No. 155 obliges a manufacturer to detect cyber-attacks, support monitoring of its vehicle types, and provide data forensic capability for analysing attempted attacks. Those duties assume logging exists. This article applies the same reasoning to the model requests engineers and agents make inside the manufacturer, and sets out the per-request record an approval authority discussion can rest on.

UN Regulation No. 155 obliges a manufacturer to run a certified Cyber Security Management System and to show, for the vehicle type seeking approval, that it can detect and prevent cyber-attacks, support its own monitoring of threats and vulnerabilities, and provide data forensic capability for analysing attempted or successful attacks. Approval authorities check the logging that makes that forensic capability real. Then the same manufacturer's powertrain team pastes a calibration table and a supplier part number into a commercial chat product, and no equivalent record exists anywhere in the enterprise. An ai audit trail automotive programmes can defend has to apply the forensic standard the CSMS already accepts for the vehicle to the traffic leaving the engineering desk.
I want to work through the gap between vehicle-side logging duties and enterprise-side model usage, why the CSMS audit misses it, and what a per-request record has to carry.
TL;DR
- R155 requires a manufacturer to detect cyber-attacks and to hold data forensic capability for the vehicle type, and approval authorities verify the logging behind both.
- The same manufacturer usually has no equivalent record for model requests carrying design data, calibration values or supplier terms out of the company.
- The CSMS audit scope tends to stop at the vehicle and its development process, which leaves enterprise AI usage unmeasured.
- A defensible record names the authenticated engineer, the programme or vehicle type, the destination model and the data class, and it gets written before the response returns.
What R155 already expects you to be able to do
R155 approval turns on a certified Cyber Security Management System plus evidence for the vehicle type. Three capabilities sit at the centre of the vehicle-side assessment: detecting and preventing attacks, supporting the manufacturer's monitoring of threats and vulnerabilities, and supplying data that lets someone analyse an attack after the fact.
Manufacturers have invested heavily in that last capability over the past five years. Vehicle security operations centres now ingest telemetry, and suppliers negotiate over which signals get logged and how long they persist.
The standard applied to the vehicle is therefore already higher than the standard applied to the engineer designing it. A vehicle can produce a forensic record of an intrusion attempt. The engineering laptop that sent an unreleased calibration map to a chat product produces a proxy line showing a domain and a byte count.
Why the CSMS audit does not catch it
In the EU, Regulation (EU) 2019/2144 ties type approval to protection against unauthorised use including cyberattacks under Article 4(5)(d), and it entered into force on 6 July 2022. CSMS assessment itself covers risk management processes across development, production and post-production. Assessors read process descriptions, sample evidence and test whether the organisation does what it documented.
Enterprise AI usage escapes that lens for a structural reason. It is not part of the vehicle development toolchain the CSMS describes, and it is not part of the vehicle's attack surface. It lives in ordinary office IT, where the governing documents talk about acceptable use rather than about forensic capability.
My view, and I recognise it cuts against how most programmes are staffed, is that the enterprise side now carries more unmanaged exposure than the vehicle side. Vehicle security has a regulation, an approval authority and a budget. Model usage by twelve thousand engineers has an intranet policy page.
The content moving through those requests is the material an approval authority would care about: threat analysis and risk assessment working documents, penetration test findings, supplier security agreements, and calibration data tied to a specific vehicle type.
What the record has to carry
The evidence that stands up gets written when the request leaves the authenticated user, before any response comes back.
Per request, the useful content covers the timestamp, the engineer authenticated through the corporate identity provider, that person's role and programme assignment, the calling application or agent, the destination provider with model name and version, the classification applied to the request body, the policy version in force, the enforcement outcome, and a hash of request and response.
Programme and vehicle-type fields do the heavy lifting in this sector. A question arriving from an approval authority or a supplier concerns a vehicle type or a specific platform, so retrieval has to run along that axis and not by user account alone. Retrieval by programme, by supplier, by person or by time range makes the record usable. The cross-regulation version of this argument sits in audit trail requirements by regulation.
Retention should follow the vehicle type approval lifecycle, which outlasts most log retention policies by years. A platform in production for a decade generates questions about decisions made early in its development.
Suppliers and agents widen the surface
Tier-one suppliers hold the same design data and answer to the manufacturer contractually rather than to the approval authority directly. A supplier engineer pasting an interface specification into a chat product sits outside the manufacturer's visibility, and the only lever there is the security agreement.
Agents inside the manufacturer create a different problem. Workflows that summarise defect reports, draft supplier correspondence or query requirements databases authenticate with service credentials, so the record names a microservice. It cannot name the engineer whose request set the workflow running, which breaks the attribution an incident analysis depends on. Binding the agent request back to the initiating person, and recording both, keeps the chain intact. We covered that pattern in agentic AI audit trail.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and any LLM endpoint. Identity resolution, classification of the request body, model routing and policy enforcement happen inline on the HTTP request before it reaches the provider, which gives the enterprise side the same kind of forensic record R155 expects on the vehicle side.
Each decision writes a signed record carrying the authenticated engineer, the role and programme assignment, the classification applied, the destination model and version, the policy version in force, the outcome and the timestamp. Records commit to append-only storage before the response returns, retention configures to match vehicle type approval lifecycles, and retrieval by person, programme, supplier, model version or time range completes in seconds. The boundary covers authenticated HTTP traffic between your people or agents and the models they call. CSMS certification, vehicle-side telemetry, threat analysis and the approval authority relationship stay with the teams that own them.
If your vehicle can produce a forensic record and your engineering desk cannot, the weaker half is where the design data actually leaves. Book a demo today.
Frequently asked questions
- Does UN R155 apply to a manufacturer's internal IT?
R155 governs vehicle type approval and the CSMS behind it, so office IT is not directly in scope. The exposure is practical rather than formal: design data leaving through model requests undermines the assessment the CSMS rests on, and an approval authority asking about protection of that data will not be satisfied by an acceptable use policy.
- Is a leaked calibration table a cyber incident under R155?
R155 concerns attacks on vehicle types, not enterprise data loss. Whether the disclosure counts as a reportable incident depends on your own incident definitions and on the applicable data protection and trade secret regimes. The record is what lets you decide instead of guess.
- Can we treat ISO/SAE 21434 work as covering this?
The engineering process standard aligns with R155 and focuses on the product lifecycle. It is a poor fit for measuring what employees send to external services, which is an enterprise security control rather than a product engineering one.
- Does blocking consumer AI sites solve it?
Blocking moves the traffic to personal devices and removes your remaining visibility. Allowing approved routes while recording every request keeps the work inside a boundary you can audit.